Compliance controller for the integration of legacy systems in smart contract asset control

ABSTRACT

The platform of the present disclosure may be configured to perform one or more methods via one or more systems to provide smart contract control over asset administration and management, where regulatory regimes may require the use of systems and protocols that would not otherwise be smart contract compatible by way of legal standards and/or technical constraints. Embodiments of the present disclosure may provide a compliance controller for integrating legacy system data and operations into a smart contract system in accordance with a regulated regime associated with an asset at the basis of the smart contract process. The platform may employ the compliance controller to interface the actions of the smart contract with the legacy systems associated with an asset controller operating outside of a blockchain corresponding to the smart contract. The asset controller may have off-chain control of the asset being administered and managed by the smart contract.

RELATED APPLICATION

The present application is a U.S. National Stage under 35 U.S.C. § 371of International Application No. PCT/US20/35628, filed on Jun. 1, 2020,which claims benefit under the provisions of 35 U.S.C. § 119(e) of U.S.Provisional Application No. 62/855,965, filed on Jun. 1, 2019, theentire contents of which are incorporated in this application byreference.

It is intended that each of the referenced applications may beapplicable to the concepts and embodiments disclosed herein, even ifsuch concepts and embodiments are disclosed in the referencedapplications with different limitations and configurations and describedusing different examples and terminology.

FIELD OF DISCLOSURE

The present disclosure generally relates to distributed ledgertechnology (DLT) integration with legacy systems. More specifically, thepresent disclosure relates to compliance protocols and integrationparameters to control an asset that is governed both on the DLT (bysmart contract deployments) and off the DLT (by asset oracles andcontrollers employing legacy systems).

BACKGROUND

Some assets, such as financial instruments (e.g., notes) and legalinstruments (e.g., property rights) may not be digitized assetscompatible with smart contract control. Moreover, such assets may begoverned by various legal and technical standards and constraints thatfall well outside of the scope of the smart contract's operativecontrol.

These assets may still, however, benefit from smart contractadministration and management, in order to perform a desired action inassociation with the asset. The desired action to be performed, however,may be dependent upon the performance of one or more actions by an assetoracle (used herein interchangeably with “asset controller”). The assetoracle may reside outside of a DLT (or other blockchain technology inoperative function with the smart contract) and be governed byregulatory regimes (e.g., legal and technical standards governing thedisposition of the asset) which are not compatible with DLTs.

Moreover, the asset oracle may require certain compliance related dataand integration parameters with its legacy systems that are capable ofbeing performed through smart contracts deployed on a DLT. Thus, theasset oracle may require certain compliance related data and theperformance of certain actions to affect the desired action upon theasset in a way that smart contract protocols do not have the technicalcapability to perform.

These oracles and legacy systems may not have the technical means togovern their processing under distributed ledger technologies and,therefore, may not be operative in a protocol compliant with smartcontracts. As such, the oracles and associated legacy systems are notcompatible with smart contract functionality and, therefore, do notenable an interfacing party to realize the technical advantages of smartcontract functionality.

The lack of DLT adoption in various industries impedes the varioustechnology advantages of smart contract functionality. The presentdisclosure provides solutions that may bridge the gap created betweenthe adoption of DLT technology and the legacy systems in order toprovide for smart contract control of a desired action relating to anasset under governance of legacy system protocols.

BRIEF OVERVIEW

This brief overview is provided to introduce a selection of concepts ina simplified form that are further described below in the DetailedDescription. This brief overview is not intended to identify keyfeatures or essential features of the claimed subject matter. Nor isthis brief overview intended to be used to limit the claimed subjectmatter's scope.

In one aspect, the present disclosure relates to a method for enablingsmart contract asset control in conjunction with off-chain legacysystems in accordance to regulatory regimes surrounding the asset, themethod comprising: defining smart contract initiation data comprising:interested party data, asset data, and a desired action to be performedwith at least one interest party and at least one asset; identifyingapplicable regulatory regimes based on the smart contract initiationdata, wherein identifying the applicable regulatory regimes comprisesretrieving a list of regulatory regimes from a database of regulatoryregimes, wherein the database of regulatory regimes comprises a listingof compliance parameters associated with each regulatory regime, whereinthe listing of compliance parameters comprises a listing of technicalstandard associated with the applicable regulatory regime, wherein thetechnical standards are technical standards associated with off-chainprotocols; deploying a smart contract based on, at least in part, on thefollowing: a first set of instructions associated with the contractinitiation data, and a second set of instructions associated with thecompliance parameters; identifying an asset controller, whereinidentifying the asset control operating comprises: accessing metadataassociated with the asset controllers, the metadata comprising:compliance standards adhered to by the asset controller, and legacysystems employed by the asset controller, wherein the legacy systems areconfigured to provide operations and transfers of compliance actions anddata required by the asset controller in order for the compliancecontroller to perform the at least one component of the desired action,and filtering a list of available asset controllers based on: thecontract initiation data, and the compliance parameters, whereinfiltering the list of available asset controllers based on the contractinitiation data comprises filtering the list of available assetcontrollers based on each asset controllers' configuration to perform atleast one component of the desired action specified in the contractinitiation data, wherein the performance of the at least one componentof the desired action by the asset controller comprises an off-chainperformance outside of a scope of the smart contract's control, andwherein filtering the list of available asset controllers based on thecompliance parameters comprises filtering the list of available assetcontrollers based on each asset controllers' compliance standards;determining requisite compliance actions for integrating with at leastone asset controller of the filtered list of available assetcontrollers; wherein determining requisite compliance actions comprisesdetermining: data to be shared and operations to be performed with thelegacy systems such that the asset controller may be enabled to performat least one component of the desired action specified in the contractinitiation parameters; identifying the legacy systems associated withthe at least one asset controller; determining interface parameters forinterfacing with the legacy systems associated with asset controller;interfacing, based on the interface parameters, with the legacy systemto perform the compliance actions required by the at least onecontroller, performing the requisite compliance actions, whereinperforming the requisite actions comprises: a performance of anoperation as required by the at least one asset controller, and asharing of compliance data as required by the at least one assetcontroller; performing a plurality of performance tests with the atleast one asset controller, wherein performing the plurality ofperformance tests comprises determining whether the at least one assetcontroller is capable to perform the at least one component of thedesired action in accordance to target performance parameters;generating integration parameters based on results from the plurality ofperformance tests, wherein generating the integration parameterscomprises: generating the integration parameters when at least oneperformance test has passed, the integration parameters comprising atleast one term by which the at least one asset controller may performthe at least one component of the desired action; identifying a desiredintegration parameters for integrating smart contract control with theat least one asset controller associated with the legacy system; andcausing a performance of the at least one component of the desiredaction based on the desired integration parameters, wherein causing theperformance of the at least one component of the desired actioncomprises integrating the desired integration parameters within thesmart contract.

Both the foregoing brief overview and the following detailed descriptionprovide examples and are explanatory only. Accordingly, the foregoingbrief overview and the following detailed description should not beconsidered to be restrictive. Further, features or variations may beprovided in addition to those set forth herein. For example, embodimentsmay be directed to various feature combinations and sub-combinationsdescribed in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this disclosure, illustrate various embodiments of the presentdisclosure. The drawings contain representations of various trademarksand copyrights owned by the Applicant. In addition, the drawings maycontain other marks owned by third parties and are being used forillustrative purposes only. All rights to various trademarks andcopyrights represented herein, except those belonging to theirrespective owners, are vested in and the property of the Applicant. TheApplicant retains and reserves all rights in its trademarks andcopyrights included herein, and grants permission to reproduce thematerial only in connection with reproduction of the granted patent andfor no other purpose.

Furthermore, the drawings may contain text or captions that may explaincertain embodiments of the present disclosure. This text is included forillustrative, non-limiting, explanatory purposes of certain embodimentsdetailed in the present disclosure. In the drawings:

FIG. 1 illustrates an example data flowchart for automating loanorigination through a virtual processing, according to some embodimentsof the present disclosure;

FIG. 2 illustrates an example data flowchart for initiating a user loanfile, according to some embodiments of the present disclosure;

FIG. 3A illustrates example data flow for a loan estimate, wherein auser loan file has not been initiated;

FIG. 3B illustrates example data flow for a loan estimate, wherein auser loan file has been initiated and not complete;

FIG. 4 illustrates a platform configuration consistent with embodimentsof the present;

FIG. 5 illustrates an example data flowchart for submitting andreceiving loan dispositions, according to some embodiments of thepresent disclosure;

FIG. 6 illustrates example user interfaces during a loan estimationprocess, according to some embodiments of the present disclosure;

FIG. 7 illustrates an example flowchart;

FIG. 8A illustrates an example user device for interfacing with avirtual processing system, according to some embodiments of the presentdisclosure;

FIG. 8B illustrates an example user device for interfacing with avirtual processing system, according to some embodiments of the presentdisclosure;

FIG. 9 illustrates an example exchange of data between parties through asecure user loan file, according to some embodiments of the presentdisclosure;

FIG. 10 illustrates an example property purchase process, according tosome embodiments of the present disclosure;

FIG. 11 illustrates a computing device compatible with variousembodiments of the present disclosure;

FIG. 12 illustrates example method steps for processing a loan estimaterequest, according to some embodiments of the present disclosure;

FIG. 13 illustrates example loan estimation process steps, according tosome embodiments of the present disclosure; and

FIG. 14 illustrates example method steps for completing incompletequalifier test datapoint sets, according to some embodiments of thepresent disclosure.

DETAILED DESCRIPTION

As a preliminary matter, it will readily be understood by one havingordinary skill in the relevant art that the present disclosure has broadutility and application. As should be understood, any embodiment mayincorporate only one or a plurality of the above-disclosed aspects ofthe disclosure and may further incorporate only one or a plurality ofthe above-disclosed features. Furthermore, any embodiment discussed andidentified as being “preferred” is considered to be part of a best modecontemplated for carrying out the embodiments of the present disclosure.Other embodiments also may be discussed for additional illustrativepurposes in providing a full and enabling disclosure. Moreover, manyembodiments, such as adaptations, variations, modifications, andequivalent arrangements, will be implicitly disclosed by the embodimentsdescribed herein and fall within the scope of the present disclosure.

Accordingly, while embodiments are described herein in detail inrelation to one or more embodiments, it is to be understood that thisdisclosure is illustrative and example of the present disclosure and aremade merely for the purposes of providing a full and enablingdisclosure. The detailed disclosure herein of one or more embodiments isnot intended, nor is to be construed, to limit the scope of patentprotection afforded in any claim of a patent issuing here from, whichscope is to be defined by the claims and the equivalents thereof. It isnot intended that the scope of patent protection be defined by readinginto any claim a limitation found herein that does not explicitly appearin the claim itself.

Thus, for example, any sequence(s) and/or temporal order of steps ofvarious processes or methods that are described herein are illustrativeand not restrictive. Accordingly, it should be understood that, althoughsteps of various processes or methods may be shown and described asbeing in a sequence or temporal order, the steps of any such processesor methods are not limited to being carried out in any particularsequence or order, absent an indication otherwise. Indeed, the steps insuch processes or methods generally may be carried out in variousdifferent sequences and orders while still falling within the scope ofthe present invention. Accordingly, it is intended that the scope ofpatent protection is to be defined by the issued claim(s) rather thanthe description set forth herein.

Additionally, it is important to note that each term used herein refersto that which an ordinary artisan would understand such term to meanbased on the contextual use of such term herein. To the extent that themeaning of a term used herein—as understood by the ordinary artisanbased on the contextual use of such term—differs in any way from anyparticular dictionary definition of such term, it is intended that themeaning of the term as understood by the ordinary artisan shouldprevail.

Regarding applicability of 35 U.S.C. § 112, ¶6, no claim element isintended to be read in accordance with this statutory provision unlessthe explicit phrase “means for” or “step for” is actually used in suchclaim element, whereupon this statutory provision is intended to applyin the interpretation of such claim element.

Furthermore, it is important to note that, as used herein, “a” and “an”each generally denotes “at least one,” but does not exclude a pluralityunless the contextual use dictates otherwise. When used herein to join alist of items, “or” denotes “at least one of the items,” but does notexclude a plurality of items of the list. Finally, when used herein tojoin a list of items, “and” denotes “all of the items of the list”.

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar elements.While many embodiments of the disclosure may be described,modifications, adaptations, and other implementations are possible. Forexample, substitutions, additions, or modifications may be made to theelements illustrated in the drawings, and the methods described hereinmay be modified by substituting, reordering, or adding stages to thedisclosed methods. Accordingly, the following detailed description doesnot limit the disclosure. Instead, the proper scope of the disclosure isdefined by the appended claims. The present disclosure contains headers.It should be understood that these headers are used as references andare not to be construed as limiting upon the subjected matter disclosedunder the header.

The present disclosure includes many aspects and features. Moreover,while many aspects and features relate to, and are described in, thecontext of loan origination, embodiments of the present disclosure arenot limited to use only in this context. Rather, this context issubmitted as an illustrative, non-limiting example, to on asset typeapplicable to the various embodiments of the present disclosure.

I. Platform Overview

This overview is provided to introduce a selection of concepts in asimplified form that are further described below. This overview is notintended to identify key features or essential features of the claimedsubject matter. Nor is this overview intended to be used to limit theclaimed subject matter's scope.

The present disclosure provides a Compliance Controller for theIntegration of Legacy Systems in Smart Contract Asset Control. Methodsand systems described herein may be collectively referred to as the“platform”. The platform of the present disclosure may be configured toperform one or more methods via one or more systems to provide smartcontract control over asset administration and management, whereregulatory regimes may require the use of systems and protocols thatwould not otherwise be smart contract compatible by way of legalstandards and/or technical constraints.

The platform may be configured to integrate the technical advantages ofsmart contract asset control with the regulatory regimes and protocolsassociated with various asset oracles and legacy systems they mayemploy, either directly or through third party providers. These oraclesand legacy systems may not have the technical means to govern theirprocessing under distributed ledger technologies and, therefore, may notoperative in a protocol compliant with smart contracts. As such, theoracles and associated legacy systems are not compatible with smartcontract functionality and, therefore, do not enable an interfacingparty to realize the technical advantages of smart contractfunctionality.

Consistent with embodiments of the present disclosure, the platform maybe configured to function in accordance to interested party data (e.g.,the user types involved), associated asset data (e.g., the asset typesinvolved), and a desired action to be performed with regard to the asset(e.g., a financial instrument, a legal right, or other form of asset).Collectively, these parameters may serve as contract initiation data fora smart contract.

It should be understood that the platform of the present disclosure maybe used to affect a disposition of a plurality of asset types,including, for example, financial instruments (e.g., notes) and legalinstruments (e.g., property rights). In certain embodiments, the assetsmay not be digitized assets compatible with smart contract control.Moreover, such assets may be governed by various legal and technicalstandards and constraints that fall well outside of the scope of thesmart contract's operative control.

Furthermore, in various embodiments, the desired action to be performedwith regard to the asset being administered by the smart contract may bedependent upon the performance of one or more actions by an asset oracle(used herein interchangeably with “asset controller”). The asset oraclemay reside outside of a blockchain (or other distributed ledgertechnology in operative function with the smart contract) and begoverned by regulatory regimes (e.g., legal and technical standardsgoverning the disposition of the asset) that are not compatible withblockchain technologies. Moreover, the asset oracle may require certaincompliance related data and integration parameters with its legacysystems that are not available through blockchain technologies. Thus,the asset oracle may require certain compliance related data and performcertain actions to affect the desired action upon the asset in a waythat smart contract protocols do not have the technical capability toperform.

To address these problems, a platform consistent with embodiments of thepresent disclosure may be configured to enable the asset oracle (andit's corresponding legacy systems) to interface with blockchain basedsystems in order to affect an operation of the smart contract that ismanaging or administering the desired action to be performed with regardto the asset.

Still consistent with embodiments of the present disclosure may providea compliance controller (referred to herein as the “main module”) forintegrating legacy system data and operations into a smart contractsystem in accordance with a regulated regime associated with an asset atthe basis of the smart contract process. The platform may employ thecompliance controller to interface the actions of the smart contractwith the legacy systems associated with an asset controller operatingoutside of a blockchain corresponding to the smart contract. The assetcontroller may have off-chain control of the asset being administeredand managed by the smart contract.

In various embodiments, the compliance controller may be configured tointegrate data communicated and processes performed with a legacy systeminto a smart contract process in accordance with regulations governingthe asset at the basis of the smart contract process. In this way, thecompliance controller may be responsible for the compliant integrationof legacy systems with smart contract operations.

It is foreseeable that in such embodiments, the asset at the basis ofthe smart contract's administration and management cannot otherwise bemanipulated by a smart contract without such compliant integration ofdata communicated and operations performed by legacy systems outside ofthe smart contract's control.

Thus, in the various embodiments disclosed herein, to deploy a smartcontract process without the use of the compliance controller of thepresent invention may prevent the smart contract from meeting thestandards and constraints established by a corresponding regulatedregime governing the asset.

The compliance controller must be capable of working with various assettypes and various regulatory regimes. In other words, a compliancecontroller must be ubiquitous/agnostic—it may be specifically designedfor any one asset type or any one regulated regime.

The compliance controller of the present disclosure may employ the smartcontract to generate the terms of the disposition of the asset inaccordance to a desired asset action and the integration parameters ithas established with legacy system integration parameters. The assetaction is designated in the contract initiation data, and wherein theintegration parameters are based on, at least in part, optimizedperformance parameters that were originally defined in the contractinitiation data.

Still consistent with embodiments of the present disclosure, as onenon-limiting example may provide, the platform may provide a process andmethod to organize and facilitate a secure and dependable loanmanagement system that does not rely on the isolated experience of anindividual. Accordingly, as one non-limiting example, the platform ofthe present disclosure may be configured to automate loan originationand estimation. In this non-limiting implementation example, a loan maybe a financial instrument (e.g., asset) that is subject to a smartcontract administration process of the present platform. Through theadministration of the financial instrument, numerous regulatory regimesand protocols (e.g., legacy systems) must be adhered to.

Such regimes and protocols are not compatible with smart contracttechnologies. To address this problem, the platform may provide acompliance controller to enable the legacy systems to effectivelyoperate with the smart contract in the administration of the financialinstrument. In this way, the technical advantages of the smart contracttechnologies are realized within the loan origination and estimationprocess.

Some of the advantages include, but are not limited to, the eliminationof dependency upon third parties (e.g., loan officers), the eliminationof costs (e.g., origination fees), and the preservation of security andprivacy. Furthermore, in some aspects, data automation of the presentdisclosure is fortified by trust enabled data validation protocolsprocessing on a decentralized network replacing the human analyticaldecision-making dependency. In some embodiments, this data structure maylessen intermediary friction, human errors, and file defects by sharingreal-time data on blocks of data processed by a network of nodes. Insome aspects, multi-party smart contracts and automated processes mayaccelerate origination, fulfillment, settlement, and serving functionsbetween multiple intermediary parties within the lending ecosystem,creating a complete blockchain origination and securitization loanlifecycle.

Most notably, one of the technical advantages of the present disclosurewith regard to the aforementioned example, is that it may enable anaspect of loan origination to ensure that the end result remainscompliant with a regulated regime governing the practice of loanorigination while employing smart contracts throughout the process. Thistechnical advantage is most apparent in view of conventional smartcontracts systems failing to meet compliance with certain regulatedregimes governing the asset under their control (e.g., a financialinstrument such as a loan) as they do not have the compliance controllerto interface with legacy systems.

Embodiments of the present disclosure may comprise methods, systems, anda computer readable medium comprising, but not limited to, at least oneof the following:

-   -   A. An End User Interface Module (UI/API);    -   B. A Legacy Systems and Asset Oracle Interface Module;    -   C. A Data Store and Gathering Module;    -   D. A Smart Contract Module; and    -   E. A Main Module.

Details with regards to each module is provided below. Although modulesare disclosed with specific functionality, it should be understood thatfunctionality may be shared between modules, with some functions splitbetween modules, while other functions duplicated by the modules.Furthermore, the name of the module should not be construed as limitingupon the functionality of the module. Moreover, each component disclosedwithin each module can be considered independently without the contextof the other components within the same module or different modules.Each component may contain language defined in other portions of thesespecifications. Each component disclosed for one module may be mixedwith the functionality of another module. In the present disclosure,each component can be claimed on its own and/or interchangeably withother components of other modules.

The following depicts an example of a method of a plurality of methodsthat may be performed by at least one of the aforementioned modules, orcomponents thereof. Various hardware components may be used at thevarious stages of operations disclosed with reference to each module.For example, although methods may be described to be performed by asingle computing device, it should be understood that, in someembodiments, different operations may be performed by differentnetworked elements in operative communication with the computing device.For example, at least one computing device 1100 may be employed in theperformance of some or all of the stages disclosed with regard to themethods. Similarly, an apparatus may be employed in the performance ofsome or all of the stages of the methods. As such, the apparatus maycomprise at least those architectural components as found in computingdevice 1100.

Furthermore, although the stages of the following example method aredisclosed in a particular order, it should be understood that the orderis disclosed for illustrative purposes only. Stages may be combined,separated, reordered, and various intermediary stages may exist.Accordingly, it should be understood that the various stages, in variousembodiments, may be performed in arrangements that differ from the onesclaimed below. Moreover, various stages may be added or removed withoutaltering or deterring from the fundamental scope of the depicted methodsand systems disclosed herein.

Consistent with embodiments of the present disclosure, a method may beperformed by at least one of the modules disclosed herein. The methodmay be embodied as, for example, but not limited to, computerinstructions, which when executed, perform the method. The method maycomprise the following stages:

-   -   1. Smart Contract Initiation Inputs    -   2. Regulatory Regime Identification    -   3. Smart Contract Deployment    -   4. Asset Oracle and Controller Identification    -   5. Integration with Legacy Systems associated with the Asset        Oracle/Controller    -   6. Interfacing the Smart Contract with the Legacy Systems    -   7. Establishing Integrated Solution    -   Optional Stages:    -   8. Selecting Integrated Solution    -   9. Establishing Smart Contract based on Integrated Solution        Parameters    -   10. Deploying the Smart Contract

Although the aforementioned method has been described to be performed bythe platform 400, it should be understood that computing device 1100 maybe used to perform the various stages of the method. Furthermore, insome embodiments, different operations may be performed by differentnetworked elements in operative communication with computing device1100. For example, a plurality of computing devices may be employed inthe performance of some or all of the stages in the aforementionedmethod. Moreover, a plurality of computing devices may be configuredmuch like a single computing device 1100. Similarly, an apparatus may beemployed in the performance of some or all stages in the method. Theapparatus may also be configured much like computing device 1100.

Both the foregoing overview and the following detailed descriptionprovide examples and are explanatory only. Accordingly, the foregoingoverview and the following detailed description should not be consideredto be restrictive. Further, features or variations may be provided inaddition to those set forth herein. For example, embodiments may bedirected to various feature combinations and sub-combinations describedin the detailed description.

II. Platform Operation

Embodiments of the present disclosure provide a hardware and softwareplatform operative by a set of methods and computer-readable mediacomprising instructions configured to operate the aforementioned modulesand computing elements in accordance with the methods. The followingdepicts an example of at least one method of a plurality of methods thatmay be performed by at least one of the aforementioned modules. Varioushardware components may be used at the various stages of operationsdisclosed with reference to each module.

For example, although methods may be described to be performed by asingle computing device, it should be understood that, in someembodiments, different operations may be performed by differentnetworked elements in operative communication with the computing device.For example, at least one computing device 1100 may be employed in theperformance of some or all of the stages disclosed with regard to themethods. Similarly, an apparatus may be employed in the performance ofsome or all of the stages of the methods. As such, the apparatus maycomprise at least those architectural components as found in computingdevice 1100.

Furthermore, although the stages of the following example method aredisclosed in a particular order, it should be understood that the orderis disclosed for illustrative purposes only. Stages may be combined,separated, reordered, and various intermediary stages may exist.Accordingly, it should be understood that the various stages, in variousembodiments, may be performed in arrangements that differ from the onesclaimed below. Moreover, various stages may be added or removed from thewithout altering or deterring from the fundamental scope of the depictedmethods and systems disclosed herein.

Consistent with embodiments of the present disclosure, a method may beperformed by at least one of the aforementioned modules. The method maybe embodied as, for example, but not limited to, computer instructions,which when executed, perform the methods below. The method may comprise,but not be limited to, the following stages.

1. Smart Contract Initiation Inputs—Stage 710

The platform may be configured to interface with a plurality of end usertypes (e.g., borrower, lender, loan officer, and other related thirdparties). The end user may be configured to provide inputs and viewoutputs via the interface module.

In various embodiments, the end user may be enabled to provide a seriesof inputs. The inputs may comprise, for example, a request for a smartcontract to control an asset. In some embodiments, the inputs may bereceived through an application programming interface in communicationwith an external platform.

The asset at the foundation of the smart contract request may beregulated under a regulatory regime. The regulatory regime may involveasset oracles and controllers who play a role in the disposition of theasset, as it relates to the request for smart contract asset control.The asset oracles and controllers, however, may not have the necessarytechnical standards and interfaces necessary to communicate with thesmart contract and vice versa. Accordingly, the platform of the presentdisclosure may provide a compliance controller (e.g., main module) beconfigured to enable the asset oracles and controllers having assetcontrol to interface with the smart contract in order to fulfill therequest.

The platform may compile the series of inputs (referred to as smartcontract control parameters or contract initiation data) into thefollowing data structure, illustrated here by way of non-limitingexample:

a) Interested Party data: Personally Identifiable Information (PII) ofat least one interested party and Other data related to at least oneinterested party in the disposition of the asset related to the smartcontract control request;

b) Asset data: specifying the type of asset and related asset parameters(e.g., loan, amount; and

c) Asset-Based Action: specifying the action to be performed by thesmart contract (e.g., loan origination) and performance parametersassociated with the action (e.g., tolerances, conditional acceptance andrejection criteria).

Together with the series of inputs, the platform may be configured togenerate a process datastore (PDS) and store the contract initiationparameters therein. The PDS may then be provided to, for example, legacysystems, for interfacing with asset controllers and oracles in order toaffect the disposition of the asset in accordance with the smartcontract control request parameters.

In turn, as will be discussed herein, the contract initiation data maybe processed by asset oracles and legacy systems associated with assetoracles to generate a plurality of action proposals. The actionproposals may be associated with the asset under control by thecontract. Different legacy systems may offer different integrationparameters, which may, in turn, result in different action proposals.The integration parameters proposed by each legacy system may be basedon the legacy systems constraints, associate asset oracle/controllerconstraints, as well as one or more compliance standards correspondingto the regulatory regime governing the assets and parties that aresubject to the desired asset action.

2. Regulatory Regime Identification—Stage 720

It is well known that various asset types are under the governance ofvarious regulatory regimes. This applies to assets being controlled by asmart contract. However, as indicated above, the regulatory regimes maybe implemented by parties (e.g., an asset controller or oracle) whoemploy legacy systems that are not compatible with blockchain technologyor distributed ledger technologies.

Thus, in accordance with embodiments of the present disclosure, theplatform may be configured to identify a plurality of regulatory regimesrelated to the asset under smart contract administration and management.

In a first instance, the platform may be configured to parse through thecontract initiation data to identify the asset type and asset parameters(e.g., asset metadata), as well as asset action performance parameters(i.e., the desired action to be performed with the asset). The platformmay then retrieve a list of regulatory regimes based on the asset databy accessing a data repository comprising the data (either internally orexternally from the platform itself).

In a second instance, the platform may be configured to parse throughthe contract initiation data to identify the interested parties andassociated parameters. For instance, the platform may obtain demographicdata, location data, and other related data, and ascertain variousregulatory regimes applicable to the interested parties.

The platform may further be configured to retrieve a listing of theregulatory regimes applicable to the asset of the smart contract by wayof identifying the proper jurisdictions related to the regime, theasset, the parties, and the desired performance parameters.

Each regulatory regime may define requirement, or compliance parameters,upon any actor who may take actions with regard to the asset. Forinstance, by way of non-limiting example, technical standards as well aslegal compliance requirements may be defined by the regulatory regime.Accordingly, as will be disclosed below, the platform must then adaptthe smart contract operations as they relate to the administration andmanagement of the asset to comply with those requirements. Compliancemay include, however, that the smart contract interface with legacysystems under certain technical standards required by the regulatoryregime.

3. Smart Contract Deployment—Stage 730

Having the regulatory regimes, associated compliance and technicalstandards, and the contract initiation data established, the platformmay now deploy the smart contract. In some embodiments, the smartcontract may be generated by the platform. For instance, the platformmay reference a definitions and terms database that may be mapped to orotherwise associated with, for example, but not limited to, theregulatory regime's standards (i.e., the compliance parameters) and thecontract initiation data.

In some embodiments, the platform may select from a database ofpre-existing smart contracts, selected based on, for example, but notlimited to, a mapping to the regulatory regime's standards and thecontract initiation data. In yet further embodiments, the templatedsmart contracts may be customized to meet the specific requirements asdefined by, for example, but not limited to, the regulatory regime'sstandards (i.e., the compliance parameters) and the contract initiationdata.

Once established, the smart contract may be deployed on a blockchaintechnology suitable, as implemented by one of ordinary skill in thefield of the present disclosure.

4. Asset Oracle and Controller Identification—Stage 740

According to embodiments of the present disclosure, the desired actionto be performed in conjunction with the asset under smart contractmanagement and administration may require an interested party to performan action. That interested party may have off-chain access, control, andauthority over the disposition of the asset in accordance to the desiredaction to be performed. The interested party may be referred to as theasset oracle or asset controller.

The platform of the present disclosure may be configured to identify aplurality of asset controllers based on, for example, but not limitedto, a mapping of the compliance parameters and contract initiation data(which may comprise asset type data and interested party data).

Each asset controller may have metadata defining various properties ofthe asset controller. The metadata may be used to determine whether ornot the asset controller is the appropriate controller to interface withthe platform. The determination may be based on, for example, but notlimited to, any one of the following: asset jurisdiction and othercompliance requirements associated with the asset, as well as contractinitiation data.

In various embodiments, the metadata may further specify which thirdparties and/or legacy systems are required by the asset controllers.

In turn, the platform may be configured to filter and select one or moredesired legacy systems to undertake the performance parameters definedin the contract initiation data. In some embodiments, a user may beenabled to select the qualifying asset controllers. In one example, aborrower may apply for a mortgage (i.e., desired action) to purchase orrefinance a home (i.e., asset type), and the borrow or loan officer mayselect a desired bank (e.g., asset controller). In some embodiments, thedesired bank may be limited in selection based on, for example, but notlimited to, the location of the user, the asset, compliance parametersassociated with the regulatory regime.

Having identified the appropriate asset oracles, the platform mayfurther be configured to identify legacy systems required forintegration with the asset controller. The legacy systems may comprise aplurality of interface parameters. The interface parameters may not becompliant with DLT protocols and, thus, may not be accessible via smartcontract execution alone. However, the platform must still interfacewith the legacy systems to perform the desired action as specified forthe smart contract.

Accordingly, in this stage, the platform may have identified theappropriate asset controller and affiliated legacy systems necessary forcompliant interface with the asset controllers, in order to affect thedisposition of the asset under smart contract management andadministration.

5. Additional Stages

Referring now to FIG. 12, example process steps for providing a loanestimate through a VPS are illustrated. At 1205, a VPS may be activated,and user information may be input. At 1210, the VPS may format and sortthe information to populate it into LOS. At 1215, the VPS may optionallyrequest additional input datapoints. In some aspects, VPS may preparecollected data for a third party. At 1220, the VPS may transmitqualifier test datapoints to third party. At 1225, the VPS may receivethe qualifier test results from the third party. At 1230, the VPS mayadd qualifier test results to user loan file. At 1235 the VPS mayoptionally identify qualifier test results that comprise datapoints forother qualifier tests. At 1240 the VPS may repeat the same process foreach qualifier test. At 1245, the VPS may optionally transmit qualifiertest results.

In some embodiments, a loan data file may be created or updated if theuser is new to the system or not. In some aspects, the loan data may beupdated in the system if it is a returning user.

In some embodiments, once information has been formatted the system maysend the information into the system. In some aspects, the system maynot have enough information to provide relevant or useful informationfrom the system which may prompt a request for more information to theuser. In some aspects, the user provided data may not meet the minimumrequirements, prompting the system to request relevant information againto restart the process.

In some embodiments, if enough data has been input into the system bythe user, the data may be used to pull and add data from a third party.In some implementations, once the third party has retrieved all relevantinformation the reviewed information may be sent back into the systemand the loan data may be updated. In some aspects, once the loan data isupdated the information may be sent to the LOS and underwriters. In someembodiments, the LOS may review the provided information, includinginformation provided by third parties and underwriters. In someimplementations, once both parties have reviewed the information, theinformation is compiled and the user may be alerted of loan options. Insome aspects, a smart contract may be drawn up for the user to sign onceloan options are presented.

Referring now to FIG. 13, example loan estimation process steps areillustrated. At 1305, a loan estimate request may be received, such asfrom a user through a network device. At 1310, input datapoints may bereceived from a user. At 1315, a user loan file may be created, whereinthe user loan file may initially comprise the input datapoints. In someaspects, the user loan file may be encrypted and accessed throughblockchain technology, which may limit tampering or security risks. At1320, a loan type may be identified, such as a mortgage loan,construction loan, auto loan, business loan, student loan, orrefinancing loan, as non-limiting examples.

At 1325, a qualifier test database may be accessed, wherein thequalifier test database may comprise data related to different loantypes, loan products, and qualifier tests. At 1330, a set of qualifiertests may be identified. In some aspects, each loan type and loanproduct may be associated with a predefined set of qualifier tests,wherein results from the set of qualifier tests may determineeligibility for a particular loan type or loan product.

At 1335, the qualifier test datapoint sets may be populated, such aswith the input datapoints. In some aspects, at 1340, the data may bemonitored for disqualifying values that may necessarily reject the userfrom eligibility for a loan that may be available through VPS. Forexample, disqualifying values may comprise a bankruptcy or tax lien. Insome embodiments, disqualifying values may comprise qualifier testresults that fall out of range for all loan products for that loan type.For example, for someone applying for a car loan, a credit score below580 may eliminate their ability to receive any loan product. As anotherexample, for someone applying for a mortgage, a debt to income ratioabove 90%, may eliminate their ability to receive any mortgage loanproducts. As another example, for any type of loan, requesting a loanamount above the value of the property, project, or endeavor mayeliminate the ability to receive that loan amount.

At 1345, completeness of the qualifier test datapoint sets may bemonitored, wherein a complete qualifier test datapoint set may comprisedata for datapoint within the set. At 1350, complete qualifier testdatapoint sets may be identified. At 1355, complete qualifier testdatapoint sets may be transmitted to their respective third party systemconfigured to process the qualifier test datapoints and providequalifier test results. At 1360, qualifier test results may be received.At 1365, the user loan file may be updated with populated qualifier testdatapoint sets, input datapoints, and qualifier test results.

Referring now to FIG. 14, example method steps for completing incompletequalifier test datapoint sets are illustrated. At 1405, incompletequalifier test datapoint sets are illustrated. At 1410, missing data maybe assessed and identified. In some aspects, at 1415, a user may beprompted for missing data. In some embodiments, at 1420, relevantqualifier test results may identified as part of the missing data. At1425, an incomplete qualifier test may be populated with the missingdata. At 1430, the user loan file may be updated. In some embodiments,the user loan file may be updated in real time, as datapoints arecollected, sorted, and populated.

III. Platform Configuration

FIG. 4 illustrates one possible operating environment through which aplatform consistent with embodiments of the present disclosure may beprovided. By way of non-limiting example, a platform 400 for providingthe methods and systems for may be hosted in both a blockchain protocol(“on-chain”) and off of a blockchain protocol (“off-chain”). It shouldbe understood that layers and stages performed by the layers may beeither “on-chain” or “off-chain.” The present disclosure anticipatesembodiments with variations as to which stages may be performed“on-chain” or “off-chain.”

Embodiments of the present disclosure provide a hardware and softwareplatform operative by a set of methods and computer-readable mediacomprising instructions configured to operate the aforementioned modulesand computing elements in accordance with the methods. The followingdepicts an example of at least one method of a plurality of methods thatmay be performed by at least one of the aforementioned modules. Varioushardware components may be used at the various stages of operationsdisclosed with reference to each module.

For example, although methods may be described to be performed by asingle computing device, it should be understood that, in someembodiments, different operations may be performed by differentnetworked elements in operative communication with the computing device.For example, at least one computing device 1100 may be employed in theperformance of some or all of the stages disclosed with regard to themethods. Similarly, an apparatus may be employed in the performance ofsome or all of the stages of the methods. As such, the apparatus maycomprise at least those architectural components as found in computingdevice 1100.

Furthermore, although the stages of the following example method aredisclosed in a particular order, it should be understood that the orderis disclosed for illustrative purposes only. Stages may be combined,separated, reordered, and various intermediary stages may exist.Accordingly, it should be understood that the various stages, in variousembodiments, may be performed in arrangements that differ from the onesclaimed below. Moreover, various stages may be added or removed from thewithout altering or deterring from the fundamental scope of the depictedmethods and systems disclosed herein.

Consistent with embodiments of the present disclosure, a method may beperformed by at least one of the aforementioned modules. The method maybe embodied as, for example, but not limited to, computer instructions,which when executed, perform the methods below.

Accordingly, embodiments of the present disclosure provide a softwareand hardware platform comprised of a distributed set of computingelements, including, but not limited to:

A. End User Interface Module (UI/API)

Referring now to FIG. 1, an example data flowchart 100 for Integrationof Legacy Systems in Smart Contract Asset Control is illustrated. Insome aspects, an end-user/interested party device 110 may be the mainpoint of contact between the end-user/interested party and theinformation they give and receive to main module 440. In someembodiments, end-user/interested party device 110 may be a smart phone,smart device, laptop, or any other non-limiting example of a computingdevice. In some embodiments, once the application has been downloaded toend-user/interested party device 110 the flowchart 100 process maybegin.

In some embodiments consistent with the present disclosure, the end-userand/or interested party may use at least one computing device, such as asmartphone, tablet, laptop, desktop, or any the device compatible with acomputing device 1100 device to access the platform. In someembodiments, an end-user and/or interested party may access their userinitiated contracts through a mobile device. In some embodiments, adownloadable version and/or web version may be available allowing forflexibility. In some implementations, each end-user/interested party mayuse a username and password based on specific criteria provided by thesystem to ensure all information is secure.

In some embodiments consistent with the present disclosure, differentparties may have access to an initiated contract at one time. In someembodiments, the platform may track, tag, and implement each update. Insome embodiments, the system may provide alerts or notifications toend-user/interested party device 110 if options change based on theirinput or updated information. In some implementations, all changes madeto the initiated contract may be simultaneously updated through thesystem and all parties involved may be alerted each time a change ismade regardless of who is currently accessing the platform. In someembodiments, all parties involved may receive copies of the dispositionof the asset. In some embodiments, the system may coordinate dispositionof the asset review as users move through the process.

In some embodiments consistent with the present disclosure, anend-user/interested party may enter data related to PersonallyIdentifiable Information (PII) of at least one interested party,financial information, target property, and other information that mayfactor into the loan process depending on the loan type. In someimplementations, once the information has been input into the system itmay be prepared and formatted by the application for review by mainmodule 440. In some aspects, the application may pull informationregarding the user from legacy systems and asset oracle interface module420. In some embodiments, legacy systems and asset oracle interfacemodule 420 may use one or more third-party databases for verification ofthe information provided or qualifier test results, such as a creditscore, rate quote, asset verification, income verification. In someimplementations, legacy systems and asset oracle interface module 420may use third party databases to pull additional information that may berequired to aid in the loaning process. In some embodiments, the usermay be prompted to input data to help the loan estimator generate betterand more accurate Action Proposals.

In some embodiments consistent with the present disclosure, the processmay be subject to manual review 150. In some implementations, mainmodule 440 may flag input the user information and switch to manualreview 150, such as where contract initiation parameters may conflictwith compliance data. In some aspects, the manual review 150 process mayoverride the results from main module 440 based on outside informationor opinion that may aid an action proposal. In some embodiments, manualreview 150 may occur after smart contract 140 has been accepted orgenerated to ensure all information is correct on main module 440 endand the contract initiation data. In some implementations, manual reviewmay be based on the type asset and/or asset action end-user isrequesting or selects.

Referring now to FIG. 6, example a pending user interface 600 and aresults interface 650 during the process are illustrated. In someembodiments, pending user interface 600 may alert the user whendifferent actions occur with their asset control process. In someimplementations, pending user interface 600 may alert the user when moreinformation may be required to update their profile or input additionalcompliance requisite. In some aspects, the user may get an alert forevery additional piece of information that is needed. For example, auser may get two separate alerts for an income qualifier datapoint and acredit score datapoint.

In some implementations, the user may receive alerts when newperformance test results are available for review. In some aspects, theuser may review their alerts on an alert or notification screen for thepending interface module interface 600. For example, all alerts that theuser has on their system may be displayed together on an alert tab orscreen on the device or in the system. In some embodiments, resultsinterface 650 may be displayed once performance test results arereceived.

Referring now to FIGS. 8A-8B, user devices 800, 850 with example userinterfaces 810, 860 are illustrated. In some aspects, the portable userdevice 800 may have full access and communication with the InterfaceModule 410. In some implementations, the portable user device 800 may beany smart device that can access the Interface Module. As non-limitingexamples, a smart phone, tablet, and laptop may all be consideredportable user devices 800, as well as any device compatible with acomputing device 1100. In some aspects, data may be input directly, suchas through use of a keyboard or a touch screen.

In some embodiments, at least a portion of interactions with theInterface Module may occur through voice activation. For example, a usermay interact with a home virtual assistant and request an actionproposal. The home virtual assistant may access the interface module,which may prompt a series of questions. User responses may be used toinitiate a Process DataStore (PDS), which may be processed for the loanestimation process. In some implementations, the PDS generated by mainmodule 440 may be accessed through the user's other devices after beingcreated by a home virtual assistant. In some aspects, the interfacemodule may request supporting documentation or additional data for theuser to provide by some other means. In some embodiments, the homevirtual assistant may ask different qualifying questions based on theloan type the user is inquiring about.

In some embodiments, the downloadable interface module interface 810 maybe downloaded from an app store on a smart device and installed onto amobile or smart device. For example, an iPhone user may go to the AppleStore and download a version of the downloadable Interface moduleinterface 810 to their iPhone. In some embodiments, the downloadableinterface module interface 810 may be a physical version that can bedownloaded onto a non-mobile device. For example, a disk version may bepurchased online or at a local store and installed on a non-mobilecomputing device such as a desktop computer so that the user has accessto the system from their home or office.

In some aspects, a web interface module interface 860 may be used on adesktop user device 850. In some embodiments, the web interface moduleinterface 860 may be accessed on a desktop user device 850. For example,if a user did not have access to a portable user device 810, they couldgo to an internet café, library, or any other non-limiting example thatmay have a desktop user device 850 and log into their profile throughthe secured web interface module interface 860. In some embodiments, theuser may create a profile on the web Interface Module interface 860 thatrequires them to come up with a unique username and password.

In some embodiments, the username may be an email connected to theaccount, a user-generated username, or a random one assigned by theInterface Module to the user. In some implementations, the password maybe a unique generated word or phrase by the user. In some aspects, thepassword requirements may include the password to have a symbol,uppercase letter, lowercase letter, certain length and othernon-limiting examples that allows the user to create a unique passwordthat only they would remember to gain access to their account.

In some embodiments, web interface module interface 860 may have asecured database within the system that limits security risk forunauthorized access to PDSs. In some implementations, web interfacemodule interface 860 may have a firewall and other security measuresthat prevent accessibility of files and information of users on thesite. For example, along with the username and password to protect theuser a security system may be set up on the website's firewall to keepunwanted viruses and hackers out of the private system. In some aspects,there may be other security measures implemented to mask or protect userdata and information. For example, record-keeping technology may be usedto track the origin of a loan as it makes its way through the process.

B. Legacy Systems and Asset Oracle Interface Module

Referring now to FIG. 3C, example data flow 300 for IntegrationParameters is illustrated, wherein a PDS has been completed. In someaspects, the data flow 300 may include a complete set of ContractInitiation Data 310. In some implementations, the Contract InitiationData 310 may include data from Legacy Systems, such as, but not limitedto FICO, VTL, DTI, housing information, employment information, andother non-limiting Compliance Requisites. In some implementations, theuser may input more data via Interface Module throughout their timeusing the platform 400. For example, if the user's credit score changes,they may update it through the Interface Module, which may trigger achange in PT 365, 370.

C. Data Store and Gathering Module

a. PDS—230

Referring now to FIG. 2, an example data flowchart 200 for initiating aProcess Datastore (PDS) 230 is illustrated. In some aspects, the datainput 210 may be user data inputted into main module 440 through anend-user/interested party device 110. In some embodiments, data input210 may include property information, identification verification,income information, and other non-limiting examples. For example, theuser may input their current housing information, income, a copy oftheir identification information, social security number, and othernon-limiting information that may factor into data input 210. In someimplementations, the information requested may depend on the Asset typeand/or asset action the user is requesting.

In some embodiments, the end-user/interested party device 110 may beused to navigate the PDS 230 and help the user edit and create theirdata input 210 for the system. In some implementations, theend-user/interested party device 110 may be a smart phone, tablet,desktop computer, laptop, or any other non-limiting example that mayallow the user to navigate the system, create and input their data input210 and view their PDS 230. In some aspects, end-user/interested partydevice 110 may only access the PDS 230 through internet connection.

In some embodiments, the data input 210 and other information generatedand input into the platform 400 may help create a PDS 230. In someimplementations, the PDS 230 may be saved and used to create futureasset control options. In some aspects, the PDS 230 may be updated oredited at any time by the user. In some embodiments, the updatingprocess may affect the action proposals for the user based on the newinformation.

For example, on original input, a user's credit score may be too low,and the user may work to increase the credit score. Months later, theuser may request an updated credit score, which may change the loandisposition. In some implementations, the PDS 230 may be saved to theplatform 400 and viewed from other platforms and different users thathave access to the PDS 230. In some embodiments, the PDS 230 may besecured through, for example, encryption technology, which may limitrisk of tampering or security breaches. For example, the PDS 230 may beviewed by a manual loan officer or funder on a desktop computer as longas they have access to the information.

b. Simultaneous PDS Access—900

Referring now to FIG. 9, an example exchange of data between parties910, 920 through a secure Process Datastore (PDS) 900 is illustrated. Insome implementations, the PDS 900 may be reviewed by a plurality ofparties 910, 920 during the review process, wherein some parties 910,920 may need access to overlapping information with the PDS 900. In someaspects, the information of the PDS 900 may be updated throughblockchain, which may limit risk of tampering or security breach. Insome embodiments, both parties 910, 920 may add and receive informationto the PDS 900. In some implementations, the information may be securedthrough some other record-keeping technology.

In some embodiments, party A 910 may add information to the PDS 900while party B 900 is viewing the current information. In someembodiments, both party A 910 and party B 920 may access PDS 900simultaneously despite accessing different portions of the PDS 900. Forexample, party A 910 could be adding Personal Identifiable Information(PII) information while party B is adjusting Asset information. In someaspects, PDS 900 may be updated in real time for each party 910, 920 asinformation is added, edited, and removed.

In some implementations, each party 910, 920 may receive notificationsas the PDS 900 is edited. In some implementations, party A 910 may be anInterested Party such as end-user, such as a borrower, and party B maybe an Asset Oracle and/or Legacy System, such as the lender or bankinginstitution. In some aspects, the parties 910, 920 may be designated ashaving permission to access a PDS 900. In some embodiments, parties maybe defined on a user by user basis, wherein only relevant parties mayhave access to a PDS 900. For example, a banking institution that iswholly unrelated to a PDS 900 may not have permission. In someembodiments, permitted parties 910, 920 may be changed and adjustedthroughout the process. For example, a Legacy System, such as a creditscore processing system, may not need access beyond the initial creditcheck process. As another example, a Legacy System, such as a titlecompany may not need access to a PDS 900 until the sale is nearingclosing.

c. Contract Initiation Data—310

Referring now to FIG. 3B, example data flow 300 for a loan estimate isillustrated, wherein a PDS has been initiated and not complete. In someaspects, the data flow 300 may occur as contract initiation data 310 isreceived. In some aspects, some of contract initiation data 310 may bepre-populated based on prior known information. For example, the usermay have used the platform 400 before and they may already have inputContract Initiation Data 310 in the platform 400. In some embodiments,the contract initiation data 310 may depend on the Asset type and/orasset action.

D. Smart Contract Module

Referring now to FIG. 10B, an example of Smart Contract process 1010 isillustrated. In some aspects, the smart contract process 1000 may beinitiated through an end-user/interested party device 110, such asthrough direct input or voice activation. In some aspects,end-user/interested party device 110 may be a smart phone, tablet,laptop or any non-liming example of a computing device 1100 that allowsthe user to access the system. In some embodiments, theend-user/interested party device 110 may allow for data input, sendingand receiving information, and viewing results, as non-limitingexamples.

In some embodiments, main module 440 may be a nexus betweenend-user/interested party device 110 and Legacy systems and asset oracleinterface module 420, wherein main module 440 may receive data fromend-user/interested party device 110 and sort the data to legacy systemsand asset oracle interface module 420. In some implementations, theplatform 400 may utilize artificial intelligence to accurately andeffectively populate the PDS, wherein algorithms integrate the benefitsassociated with extensive experience of a plurality of trusted humans.

In some aspects, main module 440 may be used to collect contractinitiation data for the smart contract process 1000 to provide accurateaction proposals for the user. In some embodiments, legacy systems andasset oracle interface module 420 may be used to retrieve informationfrom third parties. For example, legacy systems and asset oracleinterface module 420 may be used to collect credit score, employmenthistory, and other non-limiting factors that may help factor into theIntegration Parameters.

In some implementations, a smart contract 140 may be created oncesufficient information has been gathered and assessed by main module440. In some aspects, user may qualify for action proposals, and onceperformance parameters are selected, smart contract 140 may be generatedbased on the information collected by main module 1014 from the user andlegacy systems and asset oracle interface module 420. In someembodiments, smart contract 140 may be secured through blockchaintechnology, which may limit risk of tampering and may preserve theauthenticity of smart contract 140.

In some implementations, after the smart contract 140 is generated, theuser may choose to accept or reject options generated by main module440. In some aspects, if Platform 400 was not able to generate smartcontract 140 because the user does not meet the Compliance Requisites,the platform 400 may trigger a manual review 150. In some embodiments,manual review 150 may override platform 400 on a case to case basis. Forexample, if a user has low income but high property value and creditscore manual review 150 may override platform 400 and grant the user aunique smart contract 140.

Referring now to FIG. 10A, an example funding process 1080 forcollection and disbursement of encrypted funds is illustrated. In someembodiments, the funding process 1080 may occur within a secureenvironment 1086, such as Stellar mainnet. In some implementations, fundcontributors 1082 may comprise an Asset Oracle, such as a lending bank,or an end-user, such as a buyer bringing funds to closing, asnon-limiting examples. In some aspects, at closing, funds may bedisbursed through the secure environment 1086 to fund recipients 1084.

In some implementations, the asset oracle may be a fund recipient 1084if they are paying off an asset, or the asset oracle may be involved toaccept the Asset from the user, such as a funder or buyer. In someaspects, fund recipients 1084 may include legacy systems, such asgovernment agencies, escrow agencies, title companies, attorneys, orrealtors, as non-limiting examples. In some embodiments, the titlecompanies may be involved to ensure that the funds are properlydisbursed.

E. Main Module

In some embodiments of the present disclosure, information may beformatted, confirmed, and sent through main module 440 to at least oneasset oracle. In some embodiments, at least one asset oracle maydirectly interface with the legacy systems and asset oracle interfacemodule 420. In some implementations, Compliance Requisites may betransmitted to main module 440. In some aspects, main module 440 maytake information gathered from legacy systems and asset oracle interfacemodule 420 and generate integration parameters that the user may selectbased on their contract initiation data. In some embodiments, theintegration parameters may depend on the asset type an end-user selects.

a. Compliance Requisites and Performance Tests

In some embodiments, the input contract initiation data 310 may besorted into Performance Test (PT) 335, 340, 345, 350 datapoint sets,referred to as Compliance Requisites herein. As Contract Initiation Data310 is received, the PT 335, 340, 345, 350 compliance requisites may bepopulated. In some aspects, population may occur in real time. In someembodiments, population may occur in data sets, such as personalinformation, tax information, and property information, and other PII asnon-limiting examples. The aforementioned datasets may be generatedbased on Contact Initiation Data 310.

In some implementations, as a PT1 335 Compliance Requisite is complete,main module 440 may transmit the PT1 335 Compliance Requisite to atleast one Legacy System, such as external or third party system, thatmay execute the PT utilizing the PT1 335 compliance requisite. The thirdparty may transmit the results back to main module 440, wherein theresults may be stored within a PDS. In some aspects, a PT1 ComplianceRequisite 336 may comprise a necessary datapoint set for PT2 340, whichmay be populated in real time. In some implementations, ContractInitiation Data 310 may apply to multiple PT 335, 340, 345, 350, such asbirthdate, social security number, name, and other PersonallyIdentifiable Information (PII).

In some embodiments, as results are collected, they may be compared toCompliance Requisites for a set of PT 365, 370, 375. As they arecompared, failed PT 375 may be removed as soon as enough information iscollected to disqualify the PT 375, such as too low of a credit score.In some implementations, a user device 390 may indicate that the ActionProposal is pending and currently being processed. In some aspects, mainmodule 440 may eliminate and filter some action proposals, such as a15-year or 30-year loan term. In some embodiments, preference promptsmay change and adjust based on contract initiation data 310 and PT 335,340, 345, 350 results comprising compliance requisites. For example, a15-year loan term may initially be an option, but as main module 440processes the user information, a 15-year loan term may not be feasible,and the option may be removed.

b. Action Proposals

In some aspects, each PT 335, 340, 345, 350 may be associated withunique PT results 336, 341, 346, 351 based on the individual criteria ofeach test. For example, PT1 335 may collect personal information for acredit score from a legacy system, such as FICO, and PT3 345 may collectproperty information from another legacy system, such as Zillow, forFICO. In some aspects, if Compliance Requisites for a PT 335, 340, 345,350 are incomplete, the user may not be presented with an ActionProposal 360. In some embodiments, predefined results may halt theprocess. For example, an income below a predefined threshold, maypreclude a user from integration with an Asset Oracle. In some aspects,a user may request that a rejected PDS be manually reviewed.

In some aspects, the results from each PT 335, 340, 345, 350 maydirectly affect the PT 365, 370. In some embodiments, the user device390 may allow the user to access their PT 365, 370 and choose what theywould like to accept or reject. In some implementations, the user device390 may allow the user to communicate with a loan officer during themanual review process if it needs to happen. In some aspects, theplatform may provide information related to the details of each PT 365,370, allowing for an informed decision where a user may have multiple PT365, 370.

IV. Computing Device Architecture

Platform 400 may be embodied as, for example, but not be limited to, awebsite, a web application, a desktop application, backend application,and a mobile application compatible with a computing device 1100. Thecomputing device 1100 may comprise, but not be limited to the following:

-   -   Mobile computing device, such as, but is not limited to, a        laptop, a tablet, a smartphone, a drone, a wearable, an embedded        device, a handheld device, an Arduino, an industrial device, or        a remotely operable recording device;    -   A supercomputer, an exa-scale supercomputer, a mainframe, or a        quantum computer;    -   A minicomputer, wherein the minicomputer computing device        comprises, but is not limited to, an IBM AS400/iSeries/System I,        A DEC VAX/PDP, a HP3000, a Honeywell-Bull DPS, a Texas        Instruments TI-990, or a Wang Laboratories VS Series;    -   A microcomputer, wherein the microcomputer computing device        comprises, but is not limited to, a server, wherein a server may        be rack mounted, a workstation, an industrial device, a        raspberry pi, a desktop, or an embedded device;

Platform 400 may be hosted on a centralized server or a cloud computingservice. Although the disclosed methods have been described to beperformed by a computing device 1100, it should be understood that, insome embodiments, different operations may be performed by a pluralityof the computing devices 1100 in operative communication at least onenetwork.

Embodiments of the present disclosure may comprise a system having acentral processing unit (CPU) 1120, a bus 1130, a memory unit 1140, apower supply unit (PSU) 1150, and one or more Input/Output (I/O) units.The CPU 1120 coupled to the memory unit 1140 and the plurality of I/Ounits 1160 via the bus 1130, all of which are powered by the PSU 1150.It should be understood that, in some embodiments, each disclosed unitmay actually be a plurality of such units for the purposes ofredundancy, high availability, and/or performance. The combination ofthe presently disclosed units is configured to perform the stages anymethod disclosed herein.

FIG. 11 is a block diagram of a system including computing device 1100.Consistent with an embodiment of the disclosure, the aforementioned CPU1120, the bus 1130, the memory unit 1140, a PSU 1150, and the pluralityof I/O units 1160 may be implemented in a computing device, such ascomputing device 1100 of FIG. 11. Any suitable combination of hardware,software, or firmware may be used to implement the aforementioned units.For example, the CPU 1120, the bus 1130, and the memory unit 1140 may beimplemented with computing device 1100 or any of other computing devices1100, in combination with computing device 1100. The aforementionedsystem, device, and components are examples and other systems, devices,and components may comprise the aforementioned CPU 1120, the bus 1130,the memory unit 1140, consistent with embodiments of the disclosure.

At least one computing device 1100 may be embodied as any of thecomputing elements illustrated in all of the attached figures, including[list the modules and methods]. A computing device 1100 does not need tobe electronic, nor even have a CPU 1120, nor bus 1130, nor memory unit1140. The definition of the computing device 1100 to a person havingordinary skill in the art is “A device that computes, especially aprogrammable [usually] electronic machine that performs high-speedmathematical or logical operations or that assembles, stores,correlates, or otherwise processes information.” Any device whichprocesses information qualifies as a computing device 1100, especiallyif the processing is purposeful.

With reference to FIG. 11, a system consistent with an embodiment of thedisclosure may include a computing device, such as computing device1100. In a basic configuration, computing device 1100 may include atleast one clock module 1110, at least one CPU 1120, at least one bus1130, and at least one memory unit 1140, at least one PSU 1150, and atleast one I/O 1160 module, wherein I/O module may be comprised of, butnot limited to a non-volatile storage sub-module 1161, a communicationsub-module 1162, a sensors sub-module 1163, and a peripherals sub-module1164.

A system consistent with an embodiment of the disclosure the computingdevice 1100 may include the clock module 1110 may be known to a personhaving ordinary skill in the art as a clock generator, which producesclock signals. Clock signal is a particular type of signal thatoscillates between a high and a low state and is used like a metronometo coordinate actions of digital circuits. Most integrated circuits(ICs) of sufficient complexity use a clock signal in order tosynchronize different parts of the circuit, cycling at a rate slowerthan the worst-case internal propagation delays. The preeminent exampleof the aforementioned integrated circuit is the CPU 1120, the centralcomponent of modern computers, which relies on a clock. The onlyexceptions are asynchronous circuits such as asynchronous CPUs. Theclock 1110 can comprise a plurality of embodiments, such as, but notlimited to, single-phase clock which transmits all clock signals oneffectively 1 wire, two-phase clock which distributes clock signals ontwo wires, each with non-overlapping pulses, and four-phase clock whichdistributes clock signals on 4 wires.

Many computing devices 1100 use a “clock multiplier” which multiplies alower frequency external clock to the appropriate clock rate of the CPU1120. This allows the CPU 1120 to operate at a much higher frequencythan the rest of the computer, which affords performance gains insituations where the CPU 1120 does not need to wait on an externalfactor (like memory 1140 or input/output 1160). Some embodiments of theclock 1110 may include dynamic frequency change, where, the time betweenclock edges can vary widely from one edge to the next and back again.

A system consistent with an embodiment of the disclosure the computingdevice 1100 may include the CPU unit 1120 comprising at least one CPUCore 1121. A plurality of CPU cores 1121 may comprise identical the CPUcores 1121, such as, but not limited to, homogeneous multi-core systems.It is also possible for the plurality of CPU cores 1121 to comprisedifferent the CPU cores 1121, such as, but not limited to, heterogeneousmulti-core systems, big.LITTLE systems and some AMD acceleratedprocessing units (APU). The CPU unit 1120 reads and executes programinstructions which may be used across many application domains, forexample, but not limited to, general purpose computing, embeddedcomputing, network computing, digital signal processing (DSP), andgraphics processing (GPU). The CPU unit 1120 may run multipleinstructions on separate CPU cores 1121 at the same time. The CPU unit1120 may be integrated into at least one of a single integrated circuitdie and multiple dies in a single chip package. The single integratedcircuit die and multiple dies in a single chip package may contain aplurality of other aspects of the computing device 1100, for example,but not limited to, the clock 1110, the CPU 1120, the bus 1130, thememory 1140, and I/O 1160.

The CPU unit 1120 may contain cache 1122 such as, but not limited to, alevel 1 cache, level 2 cache, level 3 cache or combination thereof. Theaforementioned cache 1122 may or may not be shared amongst a pluralityof CPU cores 1121. The cache 1122 sharing comprises at least one ofmessage passing and inter-core communication methods may be used for theat least one CPU Core 1121 to communicate with the cache 1122. Theinter-core communication methods may comprise, but not limited to, bus,ring, two-dimensional mesh, and crossbar. The aforementioned CPU unit1120 may employ symmetric multiprocessing (SMP) design.

The plurality of the aforementioned CPU cores 1121 may comprise softmicroprocessor cores on a single field programmable gate array (FPGA),such as semiconductor intellectual property cores (IP Core). Theplurality of CPU cores 1121 architecture may be based on at least oneof, but not limited to, Complex instruction set computing (CISC), Zeroinstruction set computing (ZISC), and Reduced instruction set computing(RISC). At least one of the performance-enhancing methods may beemployed by the plurality of the CPU cores 1121, for example, but notlimited to Instruction-level parallelism (ILP) such as, but not limitedto, superscalar pipelining, and Thread-level parallelism (TLP).

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ a communication systemthat transfers data between components inside the aforementionedcomputing device 1100, and/or the plurality of computing devices 1100.The aforementioned communication system will be known to a person havingordinary skill in the art as a bus 1130. The bus 1130 may embodyinternal and/or external plurality of hardware and software components,for example, but not limited to a wire, optical fiber, communicationprotocols, and any physical arrangement that provides the same logicalfunction as a parallel electrical bus. The bus 1130 may comprise atleast one of, but not limited to a parallel bus, wherein the parallelbus carry data words in parallel on multiple wires, and a serial bus,wherein the serial bus carry data in bit-serial form. The bus 1130 mayembody a plurality of topologies, for example, but not limited to, amultidrop/electrical parallel topology, a daisy chain topology, and aconnected by switched hubs, such as USB bus. The bus 1130 may comprise aplurality of embodiments, for example, but not limited to:Consistentwith the embodiments of the present disclosure, the aforementionedcomputing device 1100 may employ hardware integrated circuits that storeinformation for immediate use in the computing device 1100, know to theperson having ordinary skill in the art as primary storage or memory1140. The memory 1140 operates at high speed, distinguishing it from thenon-volatile storage sub-module 1161, which may be referred to assecondary or tertiary storage, which provides slow-to-access informationbut offers higher capacities at lower cost. The contents contained inmemory 1140, may be transferred to secondary storage via techniques suchas, but not limited to, virtual memory and swap. The memory 1140 may beassociated with addressable semiconductor memory, such as integratedcircuits consisting of silicon-based transistors, used for example asprimary storage but also other purposes in the computing device 1100.The memory 1140 may comprise a plurality of embodiments, such as, butnot limited to volatile memory, non-volatile memory, and semi-volatilememory. It should be understood by a person having ordinary skill in theart that the ensuing are non-limiting examples of the aforementionedmemory:

-   -   Volatile memory which requires power to maintain stored        information, for example, but not limited to, Dynamic        Random-Access Memory (DRAM) 1141, Static Random-Access Memory        (SRAM) 1142, CPU Cache memory 1125, Advanced Random-Access        Memory (A-RAM), and other types of primary storage such as        Random-Access Memory (RAM).    -   Non-volatile memory which can retain stored information even        after power is removed, for example, but not limited to,        Read-Only Memory (ROM) 1143, Programmable ROM (PROM) 1144,        Erasable PROM (EPROM) 1145, Electrically Erasable PROM (EEPROM)        1146 (e.g. flash memory and Electrically Alterable PROM        [EAPROM]), Mask ROM (MROM), One Time Programable (OTP) ROM/Write        Once Read Many (WORM), Ferroelectric RAM (FeRAM), Parallel        Random-Access Machine (PRAM), Split-Transfer Torque RAM        (STT-RAM), Silicon Oxime Nitride Oxide Silicon (SONOS),        Resistive RAM (RRAM), Nano RAM (NRAM), 3D XPoint, Domain-Wall        Memory (DWM), and millipede memory.    -   Semi-volatile memory which may have some limited non-volatile        duration after power is removed but loses data after said        duration has passed. Semi-volatile memory provides high        performance, durability, and other valuable characteristics        typically associated with volatile memory, while providing some        benefits of true non-volatile memory. The semi-volatile memory        may comprise volatile and non-volatile memory and/or volatile        memory with battery to provide power after power is removed. The        semi-volatile memory may comprise, but not limited to        spin-transfer torque RAM (STT-RAM).

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ the communication systembetween an information processing system, such as the computing device1100, and the outside world, for example, but not limited to, human,environment, and another computing device 1100. The aforementionedcommunication system will be known to a person having ordinary skill inthe art as I/O 1160. The I/O module 1160 regulates a plurality of inputsand outputs with regard to the computing device 1100, wherein the inputsare a plurality of signals and data received by the computing device1100, and the outputs are the plurality of signals and data sent fromthe computing device 1100. The I/O module 1160 interfaces a plurality ofhardware, such as, but not limited to, non-volatile storage 1161,communication devices 1162, sensors 1163, and peripherals 1164. Theplurality of hardware is used by the at least one of, but not limitedto, human, environment, and another computing device 1100 to communicatewith the present computing device 1100. The I/O module 1160 may comprisea plurality of forms, for example, but not limited to channel I/O, portmapped I/O, asynchronous I/O, and Direct Memory Access (DMA).

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ the non-volatile storagesub-module 1161, which may be referred to by a person having ordinaryskill in the art as one of secondary storage, external memory, tertiarystorage, off-line storage, and auxiliary storage. The non-volatilestorage sub-module 1161 may not be accessed directly by the CPU 1120without using intermediate area in the memory 1140. The non-volatilestorage sub-module 1161 does not lose data when power is removed and maybe two orders of magnitude less costly than storage used in memorymodule, at the expense of speed and latency. The non-volatile storagesub-module 1161 may comprise a plurality of forms, such as, but notlimited to, Direct Attached Storage (DAS), Network Attached Storage(NAS), Storage Area Network (SAN), nearline storage, Massive Array ofIdle Disks (MAID), Redundant Array of Independent Disks (RAID), devicemirroring, off-line storage, and robotic storage. The non-volatilestorage sub-module (1161) may comprise a plurality of embodiments, suchas, but not limited to:

-   -   Optical storage, for example, but not limited to, Compact        Disk (CD) (CD-ROM/CD-R/CD-RW), Digital Versatile Disk (DVD)        (DVD-ROM/DVD-R/DVD+R/DVD-RW/DVD+RW/DVD±RW/DVD+R        DL/DVD-RAM/HD-DVD), Blu-ray Disk (BD) (BD-ROM/BD-R/BD-RE/BD-R        DL/BD-RE DL), and Ultra-Density Optical (UDO)    -   Semiconductor storage, for example, but not limited to, flash        memory, such as, but not limited to, USB flash drive, Memory        card, Subscriber Identity Module (SIM) card, Secure Digital (SD)        card, Smart Card, CompactFlash (CF) card, Solid-State Drive        (SSD) and memristor    -   Magnetic storage such as, but not limited to, Hard Disk Drive        (HDD), tape drive, carousel memory, and Card Random-Access        Memory (CRAM)    -   Phase-change memory    -   Holographic data storage such as Holographic Versatile Disk        (HVD)    -   Molecular Memory    -   Deoxyribonucleic Acid (DNA) digital data storage

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ the communicationsub-module 1162 as a subset of the I/O 1160, which may be referred to bya person having ordinary skill in the art as at least one of, but notlimited to, computer network, data network, and network. The networkallows computing devices 1100 to exchange data using connections, whichmay be known to a person having ordinary skill in the art as data links,between network nodes. The nodes comprise network computer devices 1100that originate, route, and terminate data. The nodes are identified bynetwork addresses and can include a plurality of hosts consistent withthe embodiments of a computing device 1100. The aforementionedembodiments include, but not limited to personal computers, phones,servers, drones, and networking devices such as, but not limited to,hubs, switches, routers, modems, and firewalls.

Two nodes can be said are networked together, when one computing device1100 is able to exchange information with the other computing device1100, whether or not they have a direct connection with each other. Thecommunication sub-module 1162 supports a plurality of applications andservices, such as, but not limited to World Wide Web (WWW), digitalvideo and audio, shared use of application and storage computing devices1100, printers/scanners/fax machines, email/online chat/instantmessaging, remote control, distributed computing, etc. The network maycomprise a plurality of transmission mediums, such as, but not limitedto conductive wire, fiber optics, and wireless. The network may comprisea plurality of communications protocols to organize network traffic,wherein application-specific communications protocols are layered, maybe known to a person having ordinary skill in the art as carried aspayload, over other more general communications protocols. The pluralityof communications protocols may comprise, but not limited to, IEEE 802,ethernet, Wireless LAN (WLAN/Wi-Fi), Internet Protocol (IP) suite (e.g.TCP/IP, UDP, Internet Protocol version 4 [IPv4], and Internet Protocolversion 6 [IPv6]), Synchronous Optical Networking (SONET)/SynchronousDigital Hierarchy (SDH), Asynchronous Transfer Mode (ATM), and cellularstandards (e.g. Global System for Mobile Communications [GSM], GeneralPacket Radio Service [GPRS], Code-Division Multiple Access [CDMA], andIntegrated Digital Enhanced Network [IDEN]).

The communication sub-module 1162 may comprise a plurality of size,topology, traffic control mechanism and organizational intent. Thecommunication sub-module 1162 may comprise a plurality of embodiments,such as, but not limited to:

-   -   Wired communications, such as, but not limited to, coaxial        cable, phone lines, twisted pair cables (ethernet), and InfiniB        and.    -   Wireless communications, such as, but not limited to,        communications satellites, cellular systems, radio        frequency/spread spectrum technologies, IEEE 802.11 Wi-Fi,        Bluetooth, NFC, free-space optical communications, terrestrial        microwave, and Infrared (IR) communications. Wherein cellular        systems embody technologies such as, but not limited to, 3G,4G        (such as WiMax and LTE), and 5G (short and long wavelength)    -   Parallel communications, such as, but not limited to, LPT ports.    -   Serial communications, such as, but not limited to, RS-232 and        USB    -   Fiber Optic communications, such as, but not limited to,        Single-mode optical fiber (SMF) and Multi-mode optical fiber        (MMF)    -   Power Line communications

The aforementioned network may comprise a plurality of layouts, such as,but not limited to, bus network such as ethernet, star network such asWi-Fi, ring network, mesh network, fully connected network, and treenetwork. The network can be characterized by its physical capacity orits organizational purpose. Use of the network, including userauthorization and access rights, differ accordingly. Thecharacterization may include, but not limited to nanoscale network,Personal Area Network (PAN), Local Area Network (LAN), Home Area Network(HAN), Storage Area Network (SAN), Campus Area Network (CAN), backbonenetwork, Metropolitan Area Network (MAN), Wide Area Network (WAN),enterprise private network, Virtual Private Network (VPN), and GlobalArea Network (GAN).

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ the sensors sub-module1163 as a subset of the I/O 1160. The sensors sub-module 1163 comprisesat least one of the devices, modules, and subsystems whose purpose is todetect events or changes in its environment and send the information tothe computing device 1100. Sensors are sensitive to the measuredproperty, are not sensitive to any property not measured, but may beencountered in its application, and do not significantly influence themeasured property. The sensors sub-module 1163 may comprise a pluralityof digital devices and analog devices, wherein if an analog device isused, an Analog to Digital (A-to-D) converter must be employed tointerface the said device with the computing device 1100. The sensorsmay be subject to a plurality of deviations that limit sensor accuracy.The sensors sub-module 1163 may comprise a plurality of embodiments,such as, but not limited to, chemical sensors, automotive sensors,acoustic/sound/vibration sensors, electric current/electricpotential/magnetic/radio sensors,environmental/weather/moisture/humidity sensors, flow/fluid velocitysensors, ionizing radiation/particle sensors, navigation sensors,position/angle/displacement/distance/speed/acceleration sensors,imaging/optical/light sensors, pressure sensors, force/density/levelsensors, thermal/temperature sensors, and proximity/presence sensors. Itshould be understood by a person having ordinary skill in the art thatthe ensuing are non-limiting examples of the aforementioned sensors:

-   -   Chemical sensors, such as, but not limited to, breathalyzer,        carbon dioxide sensor, carbon monoxide/smoke detector, catalytic        bead sensor, chemical field-effect transistor, chemiresistor,        electrochemical gas sensor, electronic nose,        electrolyte-insulator-semiconductor sensor, energy-dispersive        X-ray spectroscopy, fluorescent chloride sensors, holographic        sensor, hydrocarbon dew point analyzer, hydrogen sensor,        hydrogen sulfide sensor, infrared point sensor, ion-selective        electrode, nondispersive infrared sensor, microwave chemistry        sensor, nitrogen oxide sensor, olfactometer, optode, oxygen        sensor, ozone monitor, pellistor, pH glass electrode,        potentiometric sensor, redox electrode, zinc oxide nanorod        sensor, and biosensors (such as nanosensors).    -   Automotive sensors, such as, but not limited to, air flow        meter/mass airflow sensor, air-fuel ratio meter, AFR sensor,        blind spot monitor, engine coolant/exhaust gas/cylinder        head/transmission fluid temperature sensor, hall effect sensor,        wheel/automatic transmission/turbine/vehicle speed sensor,        airbag sensors, brake fluid/engine crankcase/fuel/oil/tire        pressure sensor, camshaft/crankshaft/throttle position sensor,        fuel/oil level sensor, knock sensor, light sensor, MAP sensor,        oxygen sensor (o2), parking sensor, radar sensor, torque sensor,        variable reluctance sensor, and water-in-fuel sensor.    -   Acoustic, sound and vibration sensors, such as, but not limited        to, microphone, lace sensor (guitar pickup), seismometer, sound        locator, geophone, and hydrophone.    -   Electric current, electric potential, magnetic, and radio        sensors, such as, but not limited to, current sensor, Daly        detector, electroscope, electron multiplier, faraday cup,        galvanometer, hall effect sensor, hall probe, magnetic anomaly        detector, magnetometer, magnetoresistance, MEMS magnetic field        sensor, metal detector, planar hall sensor, radio direction        finder, and voltage detector.    -   Environmental, weather, moisture, and humidity sensors, such as,        but not limited to, actinometer, air pollution sensor,        bedwetting alarm, ceilometer, dew warning, electrochemical gas        sensor, fish counter, frequency domain sensor, gas detector,        hook gauge evaporimeter, humistor, hygrometer, leaf sensor,        lysimeter, pyranometer, pyrgeometer, psychrometer, rain gauge,        rain sensor, seismometers, SNOTEL, snow gauge, soil moisture        sensor, stream gauge, and tide gauge.    -   Flow and fluid velocity sensors, such as, but not limited to,        air flow meter, anemometer, flow sensor, gas meter, mass flow        sensor, and water meter.    -   Ionizing radiation and particle sensors, such as, but not        limited to, cloud chamber, Geiger counter, Geiger-Muller tube,        ionization chamber, neutron detection, proportional counter,        scintillation counter, semiconductor detector, and        thermoluminescent dosimeter.    -   Navigation sensors, such as, but not limited to, air speed        indicator, altimeter, attitude indicator, depth gauge, fluxgate        compass, gyroscope, inertial navigation system, inertial        reference unit, magnetic compass, MHD sensor, ring laser        gyroscope, turn coordinator, variometer, vibrating structure        gyroscope, and yaw rate sensor.    -   Position, angle, displacement, distance, speed, and acceleration        sensors, such as, but not limited to, accelerometer,        displacement sensor, flex sensor, free fall sensor, gravimeter,        impact sensor, laser rangefinder, LIDAR, odometer, photoelectric        sensor, position sensor such as, but not limited to, GPS or        Glonass, angular rate sensor, shock detector, ultrasonic sensor,        tilt sensor, tachometer, ultra-wideband radar, variable        reluctance sensor, and velocity receiver.    -   Imaging, optical and light sensors, such as, but not limited to,        CMOS sensor, colorimeter, contact image sensor, electro-optical        sensor, infra-red sensor, kinetic inductance detector, LED as        light sensor, light-addressable potentiometric sensor, Nichols        radiometer, fiber-optic sensors, optical position sensor,        thermopile laser sensor, photodetector, photodiode,        photomultiplier tubes, phototransistor, photoelectric sensor,        photoionization detector, photomultiplier, photoresistor,        photoswitch, phototube, scintillometer, Shack-Hartmann,        single-photon avalanche diode, superconducting nanowire        single-photon detector, transition edge sensor, visible light        photon counter, and wavefront sensor.    -   Pressure sensors, such as, but not limited to, barograph,        barometer, boost gauge, bourdon gauge, hot filament ionization        gauge, ionization gauge, McLeod gauge, Oscillating U-tube,        permanent downhole gauge, piezometer, Pirani gauge, pressure        sensor, pressure gauge, tactile sensor, and time pressure gauge.    -   Force, Density, and Level sensors, such as, but not limited to,        bhangmeter, hydrometer, force gauge or force sensor, level        sensor, load cell, magnetic level or nuclear density sensor or        strain gauge, piezocapacitive pressure sensor, piezoelectric        sensor, torque sensor, and viscometer.    -   Thermal and temperature sensors, such as, but not limited to,        bolometer, bimetallic strip, calorimeter, exhaust gas        temperature gauge, flame detection/pyrometer, Gardon gauge,        Golay cell, heat flux sensor, microbolometer, microwave        radiometer, net radiometer, infrared/quartz/resistance        thermometer, silicon bandgap temperature sensor, thermistor, and        thermocouple.    -   Proximity and presence sensors, such as, but not limited to,        alarm sensor, doppler radar, motion detector, occupancy sensor,        proximity sensor, passive infrared sensor, reed switch, stud        finder, triangulation sensor, touch switch, and wired glove.

Consistent with the embodiments of the present disclosure, theaforementioned computing device 1100 may employ the peripheralssub-module 1162 as a subset of the I/O 1160. The peripheral sub-module1164 comprises ancillary devices uses to put information into and getinformation out of the computing device 1100. There are 3 categories ofdevices comprising the peripheral sub-module 1164, which exist based ontheir relationship with the computing device 1100, input devices, outputdevices, and input/output devices. Input devices send at least one ofdata and instructions to the computing device 1100. Input devices can becategorized based on, but not limited to:

-   -   Modality of input, such as, but not limited to, mechanical        motion, audio, visual, and tactile    -   Whether the input is discrete, such as but not limited to,        pressing a key, or continuous such as, but not limited to        position of a mouse    -   The number of degrees of freedom involved, such as, but not        limited to, two-dimensional mice vs three-dimensional mice used        for Computer-Aided Design (CAD) applications

Output devices provide output from the computing device 1100. Outputdevices convert electronically generated information into a form thatcan be presented to humans. Input/output devices perform that performboth input and output functions. It should be understood by a personhaving ordinary skill in the art that the ensuing are non-limitingembodiments of the aforementioned peripheral sub-module 1164:

-   -   Input Devices        -   Human Interface Devices (HID), such as, but not limited to,            pointing device (e.g. mouse, touchpad, joystick,            touchscreen, game controller/gamepad, remote, light pen,            light gun, Wii remote, jog dial, shuttle, and knob),            keyboard, graphics tablet, digital pen, gesture recognition            devices, magnetic ink character recognition, Sip-and-Puff            (SNP) device, and Language Acquisition Device (LAD).        -   High degree of freedom devices, that require up to six            degrees of freedom such as, but not limited to, camera            gimbals, Cave Automatic Virtual Environment (CAVE), and            virtual reality systems.        -   Video Input devices are used to digitize images or video            from the outside world into the computing device 1100. The            information can be stored in a multitude of formats            depending on the user's requirement. Examples of types of            video input devices include, but not limited to, digital            camera, digital camcorder, portable media player, webcam,            Microsoft Kinect, image scanner, fingerprint scanner,            barcode reader, 3D scanner, laser rangefinder, eye gaze            tracker, computed tomography, magnetic resonance imaging,            positron emission tomography, medical ultrasonography, TV            tuner, and iris scanner.        -   Audio input devices are used to capture sound. In some            cases, an audio output device can be used as an input            device, in order to capture produced sound. Audio input            devices allow a user to send audio signals to the computing            device 1100 for at least one of processing, recording, and            carrying out commands. Devices such as microphones allow            users to speak to the computer in order to record a voice            message or navigate software. Aside from recording, audio            input devices are also used with speech recognition            software. Examples of types of audio input devices include,            but not limited to microphone, Musical Instrumental Digital            Interface (MIDI) devices such as, but not limited to a            keyboard, and headset.        -   Data Acquisition (DAQ) devices covert at least one of analog            signals and physical parameters to digital values for            processing by the computing device 1100. Examples of DAQ            devices may include, but not limited to, Analog to Digital            Converter (ADC), data logger, signal conditioning circuitry,            multiplexer, and Time to Digital Converter (TDC).    -   Output Devices may further comprise, but not be limited to:        -   Display devices, which convert electrical information into            visual form, such as, but not limited to, monitor, TV,            projector, and Computer Output Microfilm (COM). Display            devices can use a plurality of underlying technologies, such            as, but not limited to, Cathode-Ray Tube (CRT), Thin-Film            Transistor (TFT), Liquid Crystal Display (LCD), Organic            Light-Emitting Diode (OLED), MicroLED, E Ink Display            (ePaper) and Refreshable Braille Display (Braille Terminal).        -   Printers, such as, but not limited to, inkjet printers,            laser printers, 3D printers, solid ink printers and            plotters.        -   Audio and Video (AV) devices, such as, but not limited to,            speakers, headphones, amplifiers and lights, which include            lamps, strobes, DJ lighting, stage lighting, architectural            lighting, special effect lighting, and lasers.        -   Other devices such as Digital to Analog Converter (DAC)    -   Input/Output Devices may further comprise, but not be limited        to, touchscreens, networking device (e.g. devices disclosed in        network 1162 sub-module), data storage device (non-volatile        storage 1161), facsimile (FAX), and graphics/sound cards.

All rights including copyrights in the code included herein are vestedin and the property of the Applicant. The Applicant retains and reservesall rights in the code included herein, and grants permission toreproduce the material only in connection with reproduction of thegranted patent and for no other purpose.

V. Aspects

The following disclose various Aspects of the present disclosure. Thevarious Aspects are not to be construed as patent claims unless thelanguage of the Aspect appears as a patent claim. The Aspects describevarious non-limiting embodiments of the present disclosure.

Aspect 1. A system for automating loan estimation comprising:

-   -   i. one or more processors;    -   ii. one or more memory resources comprising:        -   1. a user loan file database;        -   2. a qualifier test database comprising a plurality of            qualifier test datapoint sets associated with a plurality of            loan types, wherein results associated with each qualifier            test determine approval of each loan type;    -   iii. wherein the one or more memory resources are connectable to        a user device through a communications network, wherein the one        or more memory resources are executable by the one or more        processors to perform the steps of:        -   1. receiving a loan estimate request;        -   2. receiving input datapoints from a user;        -   3. creating a user loan file comprising the input            datapoints;        -   4. identifying a first loan type from the loan estimate            request;        -   5. accessing the qualifier test database;        -   6. identifying a first set of qualifier tests associated            with the first loan type;        -   7. populating a plurality of qualifier test datapoint sets            with input datapoints, wherein each qualifier test datapoint            set comprises datapoints necessary to execute each qualifier            test;        -   8. monitoring the plurality of qualifier test datapoint sets            for completeness;        -   9. identifying complete qualifier test datapoint sets,            wherein each datapoint in complete qualifier test datapoint            sets comprises data associated with the user loan file;        -   10. transmitting complete qualifier test datapoint sets to            one or more third party system, wherein each third party            system processes at least a portion of the complete            qualifier test datapoint sets to produce qualifier test            results;        -   11. receiving qualifier test results;        -   12. updating the user loan file with the qualifier test            results and populated qualifier test datapoint sets.            Aspect 2. The system of Aspect 1, wherein the user loan file            is stored through blockchain technology.            Aspect 3. The system of Aspect 1, wherein the one or more            memory resources are further executable to perform the steps            of:    -   i. monitoring qualifier test results and user input data for        disqualifying values, wherein disqualifying values prevent the        user from qualifying for the loan type.        Aspect 4. The system of Aspect 1, wherein the first qualifier        datapoint set is transmitted to the first third party through an        external loan origination system.        Aspect 5. The system of Aspect 4, wherein the one or more memory        resources are further executable to perform the steps of:    -   i. identifying incomplete qualifier test datapoint sets, wherein        at least one datapoint is missing data;    -   ii. assessing whether the missing data requires user input, at        least a portion of qualifier test results, or both;    -   iii. prompting user for missing data requiring user input;    -   iv. populating incomplete qualifier test datapoint sets with the        missing data.        Aspect 6. The system of Aspect 5, wherein the steps repeat until        results are received for the first set of qualifier tests and        all of qualifier test datapoint sets are complete.        Aspect 7. The system of Aspect 1, wherein the one or more memory        resources are further executable to perform the steps of:    -   i. accessing a loan product database comprising a plurality of        loan products associated with the first loan type, wherein each        of the plurality of loan products comprise minimum qualifying        requirements, wherein minimum qualifying requirements comprise        predefined threshold values for at least a portion of qualifier        test results associated with the first loan type;    -   ii. comparing qualifier test results to minimum qualifying        requirements, wherein comparing determines whether the user        qualifies for each of the plurality of loan products.        Aspect 8. The system of Aspect 7, wherein the one or more memory        resources are further executable to perform the steps of:    -   i. identifying at least one qualified loan product from the        plurality of loan products;    -   ii. applying at least a portion of qualifier test results and        populated qualifier test datapoint sets to each qualified loan        product, wherein applying determines loan terms for each        qualified loan product;    -   iii. providing loan estimation results comprising loan terms for        each qualified loan product.        Aspect 9. The system of Aspect 8, wherein the one or more memory        resources are further executable to perform the steps of:    -   i. receiving loan product preferences;    -   ii. filtering the plurality of loan products based on loan        product preferences.        Aspect 10. The system of Aspect 8, wherein the one or more        memory resources are further executable to perform the steps of:    -   i. receiving user acceptance of a first qualified loan product        and loan terms, wherein the first qualified loan product is        selected from the at least one qualified loan product;    -   ii. creating a smart contract based on the first qualified loan        product and loan terms, wherein the smart contract initiates a        lending process.        Aspect 11. A method for automating loan estimation comprising:    -   i. receiving a loan estimate request;    -   ii. receiving input datapoints from a user;    -   iii. creating a user loan file comprising the input datapoints;    -   iv. identifying a first loan type from the loan estimate        request;    -   v. accessing a qualifier test database;    -   vi. identifying a first set of qualifier tests associated with        the first loan type;    -   vii. populating a plurality of qualifier test datapoint sets        with input datapoints, wherein each qualifier test datapoint set        comprises datapoints necessary to execute each qualifier test;    -   viii. monitoring the plurality of qualifier test datapoint sets        for completeness;    -   ix. identifying a first complete qualifier test datapoint set,        wherein each datapoint in the first complete qualifier test        datapoint set comprises data associated with the user loan file;    -   x. transmitting complete qualifier test datapoint sets to one or        more third party system, wherein each third party system        processes at least a portion of the complete qualifier test        datapoint sets to produce qualifier test results;    -   xi. receiving qualifier test results;    -   xii. updating the user loan file with the qualifier test results        and populated qualifier test datapoint sets.        Aspect 12. The method of Aspect 10, wherein the user loan file        is stored through blockchain technology.        Aspect 13. The method of Aspect 10, further comprising:    -   i. monitoring qualifier test results and user input data for        disqualifying values, wherein disqualifying values prevent the        user from qualifying for the loan type.        Aspect 14. The method of Aspect 10, wherein the first qualifier        datapoint set is transmitted to the first third party through an        external loan origination system.        Aspect 15. The method of Aspect 14, further comprising:    -   i. identifying incomplete qualifier test datapoint sets, wherein        at least one datapoint is missing data;    -   ii. assessing whether the missing data requires user input, at        least a portion of qualifier test results, or both;    -   iii. prompting user for missing data requiring user input;    -   iv. populating incomplete qualifier test datapoint sets.        Aspect 16. The method of Aspect 15, wherein the process repeats        until results are received for the first set of qualifier tests        and all of qualifier test datapoint sets are complete.        Aspect 17. The method of Aspect 10 further comprising:    -   i. accessing a loan product database comprising a plurality of        loan products associated with the first loan type, wherein each        of the plurality of loan products comprise minimum qualifying        requirements, wherein minimum qualifying requirements comprise        predefined threshold values for at least a portion of qualifier        test results associated with the first loan type;    -   ii. comparing qualifier test results to minimum qualifying        requirements, wherein comparing determines whether the user        qualifies for each of the plurality of loan products.        Aspect 18. The method of Aspect 17, further comprising:    -   i. identifying at least one qualified loan product from the        plurality of loan products;    -   ii. applying at least a portion of qualifier test results and        populated qualifier test datapoint sets to each qualified loan        product, wherein applying determines loan terms for each        qualified loan product;    -   iii. providing loan estimation results comprising loan terms for        each qualified loan product.        Aspect 19. The method of Aspect 18, further comprising:    -   i. receiving loan product preferences;    -   ii. filtering the plurality of loan products based on loan        product preferences.        Aspect 20. The method of Aspect 18, further comprising:    -   i. receiving user acceptance of a first qualified loan product        and loan terms, wherein the first qualified loan product is        selected from the at least one qualified loan product;    -   ii. creating a smart contract based on the first qualified loan        product and loan terms, wherein the smart contract initiates a        lending process.

1. Contract Initiation Data Stage

-   -   1. Retrieving a request for a smart contract to control an asset        within a regulated regime        -   1. Request for smart contract comprises at least the            following initiation parameters:            -   1. Personally Identifiable Information (PII) of at least                one interested party            -   2. Other Data related to Interested Party    -   2. Identify Asset for Smart Contract Control        -   1. Asset Type        -   2. Asset Parameters Based on Asset Type (e.g., Age of Asset,            History of Asset, Asset Location)    -   3. Identify Asset-based Action to be performed by Smart Contract        -   1. Identify Action such as, but not limited to,            -   1. Buy            -   2. Sell            -   3. Trade            -   4. Obtain a loan        -   2. Desired Performance Parameters:            -   1. Minimum and Maximum Tolerances for various parameters            -   2. Conditional Accept/Reject Requirements            -   3. e.g., term, amount, etc.    -   4. Generate Process Datastore (PDS) and store Contract        Initiation Parameters in the generated PDS

2. Regulatory Regime Setup Stage

-   -   1. Assess Contract Initiation Data from PDS        -   1. Interested party:            -   1. Retrieve List of Interested Party            -   2. Retrieve Interested Party Metadata associated with                each interested party        -   2. Asset Data:            -   1. Retrieve List of Assets            -   2. Retrieve Asset Metadata associated with each Asset        -   3. Desired Performance Parameters    -   2. Retrieve a list of available Regulatory Regimes        -   1. The list is based on at least one of the following:            -   1. Jurisdiction over at least one Interested Party            -   2. Jurisdiction over at least one Asset            -   3. Jurisdiction over at least one Desired Performance                Parameter    -   3. Filter a plurality of Regulation Regimes from the list of        available Regulation Regimes based on, at least in part:        -   1. Interested Party Metadata        -   2. Asset Metadata        -   3. Wherein filtering comprises filtering based on            Jurisdiction Data.    -   4. Retrieve and Store in the PDS, Smart Contract Requisite        Compliance Parameters associated with the at least one        applicable Regulatory Regime, comprising:        -   Technical Standards based on the at least one applicable            Regulatory Regime        -   Retrieve and Store Constraints based on selected applicable            Regimes

3. Smart Contract Generation/Selection and Deployment Stage:

-   -   1. Generate/Retrieve a smart contract based at least in part on        the PDS    -   2. Deploy the Smart Contract on the blockchain

4. Asset Oracle and Controller Identification Stage

-   -   1. Identifying of Asset Oracles/Controllers (e.g., Bank)        -   1. Retrieve a list of available asset oracles/controllers        -   2. Retrieve metadata associated with each asset            oracle/controller            -   1. Metadata Comprises:                -   1. Compliance Requisites (e.g., Verified ID, Credit                    Score, Etc.)                -    1. Retrieve a list Associated Legacy Systems based                    on Compliance Requisites                -   2. Interface Parameters (e.g., communication                    protocol)        -   3. Check Metadata for Adherence to:            -   1. PDS, including:                -   1. the regulated Regime Standards (compliance                    parameters)                -   2. Contract Initiation Data (e.g., user location &                    asset type)        -   4. Filter only adherent Asset Oracles    -   2. Identify Legacy Systems (e.g., FICO/Freddy Mac)        -   1. Retrieve a list of available legacy systems associated            with each Asset Oracle            -   1. This is based on the Compliance Requisites retrieved                from each compliant Asset Oracle/controller,        -   2. Retrieve metadata associated with legacy systems            -   1. Metadata includes:                -   1. Interface Parameters (e.g., communication                    protocol)        -   3. Check Metadata for Adherence to:            -   1. PDS, including:                -   1. the regulated Regime Standards                -   2. Contract Initiation Data (e.g., user location &                    asset type)        -   4. Filter out all Asset Oracles that are associated with            non-adherent Legacy Systems        -   5. Store the list of adherent Oracles in the PDS    -   3. Optional Embodiment:        -   1. USER INTERFACE ENABLES REVIEW/SELECTION BY:            -   1. Borrower, or            -   2. Loan Officer                5. Update PDS with Integration Parameters for Interface                with each compliant Asset Oracle

In this stage, we take our Contract Initiation Data and send the data toall the compliant oracles and their legacy systems.

-   -   1. For each Asset Oracle in the filtered list of asset oracles        perform the following:        -   1. Retrieve Compliance Requisites required for a compliant            integration (e.g., offer)            -   1. Retrieve a list of legacy Systems        -   2. Interface with each legacy system in the list of the            legacy systems to retrieve data required for a compliant            integration        -   3. Store compliance data comprising retrieved data required            for a compliant integration, in the PDS        -   4. Generate integration parameters from PDS comprised of,            for example, the following(may include other data):            -   1. Execute Performance Tests (PTs) on a smart contract                Based on:                -   1. Contract Initiation Data                -   2. Compliance Data, and                -   3. Other data provided/modified by any user                    (Interested party/Loan Officer)                    6. Smart contract to Optimize Proposal for                    Integration

Here we iterate through all Oracles and we tweak performance parameters(e.g., tolerances for loan terms) to get a different integrationparameters (proposed loan terms based on qualifications) from eachOracle, we then curate the best parameters to present to the interestedparty.

-   -   1. In some implementations, consumer initiated loan application        and origination data commands are mapped to appropriate fields        within the LOS automating processes that previously required a        manual action.    -   2. Iterative Feedback process with each Asset Oracle for        retrieval of Offer, comprising:        -   1. Retrieving PDS        -   2. Optimize Performance parameters            -   1. Optimized performance parameters based on desired                performance parameters        -   3. Provide Integration parameters and Optimized Performance            parameters        -   4. Retrieve Action Proposal(s) from each Asset Oracle    -   3. Store all Action Proposals in the PDS        7. Contract acceptance

In some embodiments, the final stage of the smart contract will be togenerate for the terms of the disposition of the asset in accordance tothe asset action based on the legacy system integration parameters,wherein the asset action is designated in the contract initiation data,and wherein the integration parameters are the optimized performanceparameters that were originally designated in the contract initiationdata.

-   -   1. Present Action Proposals to interested party via end-user        interface module    -   2. User accepts an Action Proposal from the list of presented        Action Proposals    -   3. Compliance controller sends signal of acceptance to smart        contract    -   4. Smart contract generates terms for accepted Action Proposal    -   5. Smart contract provides terms to compliance controller    -   6. Smart contract terminates    -   7. Compliance controller provides terms to all parties        Aspect 21. The method of claim 1, wherein the requisite        compliance actions comprise:    -   a performance of an operation as required by the asset        controller; and    -   a sharing of compliance data as required by the asset        controller.

VI. Claims

While the specification includes examples, the disclosure's scope isindicated by the following claims. Furthermore, while the specificationhas been described in language specific to structural features and/ormethodological acts, the claims are not limited to the features or actsdescribed above. Rather, the specific features and acts described aboveare disclosed as example for embodiments of the disclosure.

Insofar as the description above and the accompanying drawing discloseany additional subject matter that is not within the scope of the claimsbelow, the disclosures are not dedicated to the public and the right tofile one or more applications to claims such additional disclosures isreserved.

The following is claimed:
 1. A method for enabling smart contract assetcontrol in conjunction with off-chain legacy systems in accordance toregulatory regimes surrounding the asset, the method comprising:defining smart contract initiation data comprising: interested partydata, asset data, and a desired action to be performed with at least oneinterest party and at least one asset; identifying applicable regulatoryregimes based on the smart contract initiation data, wherein identifyingthe applicable regulatory regimes comprises retrieving a list ofregulatory regimes from a database of regulatory regimes, wherein thedatabase of regulatory regimes comprises a listing of complianceparameters associated with each regulatory regime, wherein the listingof compliance parameters comprises a listing of technical standardassociated with the applicable regulatory regime, wherein the technicalstandards are technical standards associated with off-chain protocols;deploying a smart contract based on, at least in part, on the following:a first set of instructions associated with the contract initiationdata, and a second set of instructions associated with the complianceparameters; identifying an asset controller, wherein identifying theasset control operating comprises: accessing metadata associated withthe asset controllers, the metadata comprising: compliance standardsadhered to by the asset controller, and legacy systems employed by theasset controller, wherein the legacy systems are configured to provideoperations and transfers of compliance actions and data required by theasset controller in order for the compliance controller to perform theat least one component of the desired action, and filtering a list ofavailable asset controllers based on: the contract initiation data, andthe compliance parameters, wherein filtering the list of available assetcontrollers based on the contract initiation data comprises filteringthe list of available asset controllers based on each asset controllers'configuration to perform at least one component of the desired actionspecified in the contract initiation data, wherein the performance ofthe at least one component of the desired action by the asset controllercomprises an off-chain performance outside of a scope of the smartcontract's control, and wherein filtering the list of available assetcontrollers based on the compliance parameters comprises filtering thelist of available asset controllers based on each asset controllers'compliance standards; determining requisite compliance actions forintegrating with at least one asset controller of the filtered list ofavailable asset controllers; wherein determining requisite complianceactions comprises determining: data to be shared and operations to beperformed with the legacy systems such that the asset controller may beenabled to perform at least one component of the desired actionspecified in the contract initiation parameters; identifying the legacysystems associated with the at least one asset controller; determininginterface parameters for interfacing with the legacy systems associatedwith asset controller; interfacing, based on the interface parameters,with the legacy system to perform the compliance actions required by theat least one controller, performing the requisite compliance actions,wherein performing the requisite actions comprises: a performance of anoperation as required by the at least one asset controller, and asharing of compliance data as required by the at least one assetcontroller; performing a plurality of performance tests with the atleast one asset controller, wherein performing the plurality ofperformance tests comprises determining whether the at least one assetcontroller is capable to perform the at least one component of thedesired action in accordance to target performance parameters;generating integration parameters based on results from the plurality ofperformance tests, wherein generating the integration parameterscomprises: generating the integration parameters when at least oneperformance test has passed, the integration parameters comprising atleast one term by which the at least one asset controller may performthe at least one component of the desired action; identifying a desiredintegration parameters for integrating smart contract control with theat least one asset controller associated with the legacy system; andcausing a performance of the at least one component of the desiredaction based on the desired integration parameters, wherein causing theperformance of the at least one component of the desired actioncomprises integrating the desired integration parameters within thesmart contract.
 2. The method of claim 1, wherein defining the smartcontract initiation data comprises defining asset data, wherein theasset data comprises: a definition of an asset, the definition of theasset comprising: an asset type, and at least one asset parameter, theat least one asset parameter comprising: an age of asset, a history ofthe asset, and a location of the asset.
 3. The method of claim 2,wherein defining the smart contract initiation data comprises defining adesired action, to be performed by the smart contract, in relation tothe asset.
 4. The method of claim 3, wherein defining the desired actioncomprises defining desired performance parameters associated with: abrokering of a transaction associated with the asset, The transactionbeing at least one of the following: a purchase associated with theasset, a sale associated with the asset, a loan associated with theasset, a trade associated with the asset, and a transfer associated withthe asset, an origination of a note associated with the asset, and ageneration of a financial instrument associated with the asset,
 5. Themethod of claim 3, wherein defining the desired action comprisesdefining desired performance parameters, the desired performanceparameters comprising: minimum and maximum tolerances for variousparameters, and conditional accept/reject requirements.
 6. The method ofclaim 1, wherein defining the smart contract initiation data comprisesdefining interested party data.
 7. The method of claim 6, whereindefining the interested party data comprises defining at least oneinterested party comprising at least one of the following: borrower,loan officer, and lender.
 8. The method of claim 1, wherein identifyingthe applicable regulatory regime comprises analyzing at least one of thefollowing: the interested party data, the asset data, and the desiredaction.
 9. The method of claim 8, wherein analyzing comprisesidentifying an applicable jurisdiction associated with at least one ofthe following: the interested party data, the asset data, and thedesired action.
 10. The method of claim 1, further comprisingidentifying legal standards associated with the at least one applicableregulatory regime.
 11. The method of claim 10, further comprisingstoring the technical standards and the legal standards associated withthe at least one applicable regulatory regime.
 12. The method of claim1, wherein accessing the metadata associated with the asset controllerscomprises accessing the metadata in order to determine at least one ofthe following: whether each asset controller meets criteria of contractinitiation data, whether each asset controller is compliant withcompliance parameters. legacy systems need to be used to interface, andintegration parameters are necessary for the performance of the desiredaction.
 13. The method of claim 1, further comprising: determiningwhether the at least one asset controller is configured to perform atleast one component of the desired action defined in the contractinitiation data.
 14. The method of claim 1, further comprising:determining whether the at least one asset controller is configured toperform at least one component of the desired action based on theproposed performance parameters defined in the contract initiation data.15. The method of claim 1, further comprising: determining whether theat least one asset controller has the necessary jurisdiction based onthe asset type.
 16. The method of claim 1, further comprising:determining whether the at least one asset controller has the necessaryjurisdiction based on a property of at least one interested party. 17.The method of claim 1, further comprising: determining whether the atleast one asset controller has the necessary jurisdiction based on aproperty of the desired action.
 18. The method of claim 1, furthercomprising: determining whether the at least one asset controller hasthe necessary jurisdiction based on at least one proposed performanceparameter associated with the desired action.
 19. The method of claim 1,wherein identifying the legacy systems comprises identifying the legacysystems based on the metadata retrieved from each corresponding assetcontroller employing the legacy systems.
 20. The method of claim 19,further comprising retrieving interface parameters associated with thelegacy systems, the interface parameters specifying how to interfacewith the legacy system.
 21. The method of claim 1, wherein the requisitecompliance actions comprise: a performance of an operation as requiredby the asset controller; and a sharing of compliance data as required bythe asset controller.